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I. INTRODUCTION 



The purpose of this thesis is to expand upon the concepts of relational/object- 
oriented database systems. Much research is being conducted in the area of database 
technology. Most research, however, centers around query optimization, distributed 
databases, multimedia databases, and expert systems [EN89]. Some research is 
being conducted in the area of object-oriented (OO) databases; however, most of 
this research appears to be directed towards designing OO databases for specific 
types of applications such as computer aided software engineering (CASE) and 
computer aided design (CAD) tools. 

There has been some research done in the area of combining relational database 
technology with object-oriented databases, and, two separate models have been 
proposed. The first approach states that to achieve a relational/object-oriented 
database management system (R/OODBMS), the object-orientation should be built 
on top of an existing relational database [PBRV90]. Specifically, an object-oriented 
interface is created to mask the underlying relational database. This interface 
appears to perform queries, updates, etc. on objects, but it actually performs the 
operations on the data that is stored in the relational database management system 
(R/DBMS) to manipulate the data. The other school of thought is to add relational 
operations to an object-oriented database [Nels88, NMO90]. This means that an 
object-oriented database is responsible for the storage and retrieval of objects. 
Relational operations (i.e., relational queries) are performed by methods associated 
with objects of the type Relation. The relational operations are built into the object- 
oriented database by adding a class Relation to it. This thesis follows the latter 
approach. 
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The main reason that most people choose 00 databases is because they are 
storing and manipulating data that cannot ordinarily be handled by conventional 
databases. Good examples of these are CAD projects and CASE tools. These types 
of applications generally require the ability to store and manipulate graphical objects 
as opposed to textual objects. In contrast, relational databases serve a very useful 
purpose in most business applications where the bulk of data being stored and 
manipulated is simply textual or numeric data that can be stored and manipulated by 
normal conventional means. The idea behind this thesis is to join the two different 
types of database paradigms into a single fully functioning database model and to 
consider alternative ways of implementing relational operations in an object- 
oriented database. 

This relational/object-oriented database can be shown to be a complete 
relational system because it provides the five core relational operations upon which 

all other operations can be constructed 1 . The five basic relational operations are built 
into the database management system (DBMS) instead of creating an artificial layer 
above the DBMS for them. This allows the user to create a database that is capable 

of storing and retrieving objects as well as performing SQL-like 2 queries on the 
database. 

The database is designed in Prograph 3 [TGS88a, TGS88b, TGS91], an object- 

oriented programming language (OOPL) available on the Apple Macintosh 4 . This 
language was chosen because it contains primitive operations for all database 
functions (i.e., disk reads and writes, opening keys, tables, etc.), so there is no need 

1. This will be discussed further in Chapter III. 

2. SQL stands for Structured Query Language and was designed and implemented by IBM Research 
as an interface for a relational database system [EN89]. It has become the defacto standard for the 
relational database industry. 

3. Prograph is a trademark of The Gunakara Sun Systems, Ltd. 

4. Apple and Macintosh are registered trademarks of Apple Computers, Inc. 
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to create them. The database system created as part of this thesis is a functional, 
albeit minimal, R/OODBMS. The number of ‘extra’ features was minimized for 
clarity. Prograph also handles list processing and manipulation of non-conventional 
objects (i.e., pictures, sounds, etc.) very easily which is important to the project’s 
design. 

The remainder of this thesis is organized as follows. Chapter II is a survey of 
the literature that forms the background for this research. It sets the stage for future 
discussion in this thesis, and provides an overview of the main topics of this thesis: 
object-oriented programming, databases, and Prograph. Chapter III presents a 
detailed description of the problem addressed in this thesis, the implementation of 
relational operations in an object-oriented database. There is also some discussion 
on how this idea has been implemented by others, and problems associated with 
these implementations. Chapter IV describes the findings of this research. Chapter 
V provides a summary, conclusions, and suggestions for future research. Appendix 
A is a description of how to use the tools provided to create a database application. 
Appendix B is the graphical representation of the attributes and methods for each 
class and Appendix C is the source code for the implementation of this system. 
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II. SURVEY OF THE LITERATURE 



This chapter deals with three major topics: object-oriented programming 
(OOP), database management systems, and the object-oriented programing 
language Prograph. Basic terminology and concepts are discussed in this chapter. 
No assumptions are made about the readers level of knowledge in these three areas. 
However, some familiarity with OOP and database topics may be helpful in fully 
understanding the material. This chapter is intended to serve as an introduction to 
these three topics, laying the groundwork for the rest of this thesis. 

A. OBJECT-ORIENTED PROGRAMMING 

Object-oriented programming is a relatively new area of programming whose 
origin has been attributed to the programming languages Simula and Smalltalk 
[Booc91,Mica88, SB86]. Although OOP seems to be the hottest sales item in pro- 
gramming and program design today, there are very few standards that clearly define 
it. Most agree that for a language to be considered object-oriented it must support at 
a minimum objects, classes, and inheritance [Nels90a], 

Creating complex applications using an object-oriented programming language 
(OOPL) is usually simpler than designing the same program using a more conven- 
tional procedural language. This is because 00 design more closely mirrors the real 
world entities being modeled. Also, the use of encapsulation (data hiding) and inher- 
itance make classes more reusable. As an example, a program written in C in a win- 
dowing environment that prints a “Hello World” window takes approximately 42 
lines of code. The same program written in Actor (an object-oriented programming 
environment) takes just two lines of code. This is because there is a Window class 
declared in the class hierarchy of Actor and the programmer only has to create an 
instance of this class to make the window. [Wu90] 
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The development of 00 programs is dependent upon the careful design of the 
classes and their relationships to one another. If the classes accurately reflect the sys- 
tem being designed and if the external interfaces are designed properly, creating a 
working program is fairly simple. This is the reason that the design of a program is 
very closely tied to the actual implementation. In Ada, for example, the actual struc- 
ture of the program may not reflect the structure of the system due to language con- 
straints [Mica88]. Ada has no mechanism to support inheritance, so the design of a 
class would most likely include some variables and procedures that have already 
been defined elsewhere. Ada does takes advantage of libraries of different types of 
functions such as math libraries, etc.; however, the programmer can only use the 
functions provided in the library ‘as is’. If there is some functionality provided by a 
certain library function, but it does not work exactly the way the programmer wants, 
or if he would like to add functionality to the existing function, then the programmer 
must make a copy of the function to be used in his program. This is because there is 
no way to use an Ada library function as a foundation to be built upon. 

The following sections present a more detailed introduction to some of the spe- 
cific areas of object-oriented programming. The main areas to be discussed are 
classes and objects, inheritance, encapsulation, reusability, and polymorphism. 

1. Classes and Objects 

A class is defined as “a set of objects that share a common structure and a 
common behavior” [Booc91; page 93]. An object is a set of self-contained variables 
with a set of procedures which operate on them [Nels90a], They do not exist in the 
text of the program, but rather in the memory of the computer while the program is 
being executed [Meye88]. Another way to view a class is as a framework or a 
blueprint that describes all instances. It is also helpful to visualize a class as a static 
entity, and an object as a dynamic entity [Meye88]. That is, once a class is defined 
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it does not change. In contrast, objects are constantly being created, modified, and 
deleted during the program’s execution. For example, if the structure of an object is 
defined as having attributes labeled X, Y, and Z, then the values stored in X, Y, and 
Z can change many times during the life of the object. 

It is helpful to think of a class as the general description of an object. For 
example, one could declare a class called Person which describes all the common 
features of people in general. A specific Person, such as John Smith, is an object 
(instance) of this class. The class description serves as an abstract description of 
related objects and how they interact with each other and the outside world. All 
objects of class Person share the same structure (attributes) and behavior (things 
they can do). It is this basic structure and behavior declaration that makes up the 
class definition. The value of a certain attribute of a Person may be different for 
every instance, but all instances have the same type of attributes. 

The description of a class is broken down into attributes and methods 
(behaviors). Continuing with the Person example, some attributes of this class 

might be weight, color _hair, birthday, etc. (see Figure 2.1 *). Attributes of a class can 
be further broken down into two distinct groups: class attributes and instance 
attributes. 



Class: Person 

Superclass: none 

Class attributes: total_population 

Instance attributes: weight, color_hair, birthday 

Methods: be_born, do_work 



Figure 2.1 Example Class Definition 



1. This figure is based upon the language independent class definition as presented in [Nels90a]. 
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Class attributes not only share their names with all the instances of the 
class, but the value of the class attribute is also shared by all instances [Nels90a]. 
For example, in class Person, there might be a class attribute total population. As 
each new Person is created, total population would be incremented, and as an 
instance is destroyed (dies) total population would be decremented. However, the 
value is the same for all instances of the class. In other words, if one instance of 
Person, say John Doe, requires the total population for some computation, the 
value is locally accessible to him and any modification to the value will be 
immediately visible to all other instances of the class. 

Instance attributes share only their names with other instances of the class; 
the values stored in the instance attributes can (and usually do) differ from one 
instance to another. The attributes weight, color Jxair, and birthday in Figure 2.1 are 
examples of instance attributes. While each instance has this set of attributes, the 
values stored vary from one instance to the next. 

Methods describe actions for classes. They are accessed by passing 
messages to an object. The concept of message passing comes from Smalltalk 
where the means for causing an object to perform some function (method) is through 
message passing [Booc91 , Nels90a]. Methods defined for the class Person in Figure 
2.1 include be_born (make a new instance of the class) and do_work. In some 
languages the only way to access an object’s attributes is through the object’s 
methods. This allows the creator of a class to modify its internal structure without 
the outside users of the class being aware of the change. This idea is called 
encapsulation , and is discussed in Section 3. 

The external interface of an object is the way the object appears to the 
users of the class. In C++ terminology, the external interface of an object is the set 
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of public attributes and public methods, as well as the specifications for these 
methods. The external interface of an object also describes the methods available for 
the object and how the messages for the object should be appear. Protected methods 
are available to a class and its descendants, and although they are not part of the end- 
user’s view of a class, they are visible to descendants of a class and the end-user 
must be aware of these methods and attributes. 

One particularly interesting type of object is the composite object 
(sometimes referred to as an aggregate object). A composite object is an object that 
is made up of other objects. In other words some (or all) of the attributes of an object 
are themselves objects. These objects that make up the composite object can be 
either sub-objects, or dependent objects, the distinction being dependent objects are 
actually objects, and sub-objects are pointers to objects. [Nels90a] 

2. Inheritance 

Inheritance is what separates OOPLs from procedural languages such as 
Ada or Pascal [Mica88]. Inheritance can be defined as a mechanism that allows for 
code sharing. It allows new classes to be defined based on an existing class or classes 
[Nels90a, SB86]. The existing class is referred to as the superclass, while the new 
class is referred to as a subclass of the existing class. In Figure 2.2, class A is the 
superclass of class B, and class B is a subclass of class A. Class B inherits all of the 
attributes and methods of class A (including any inherited by A); it may also define 
new attributes and methods to augment the inherited ones. 

There are two types of inheritance, single inheritance and multiple 
inheritance. Single inheritance means that a class can have ‘at most’ one superclass 



2. Public methods/attributes are those methods/attributes that are available to all methods and users 
of the class. 
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Figure 2.2 Superclass/Subclass Example 

and is generally referred to as simply ‘inheritance’. Multiple inheritance (MI) 
means that a class can have many superclasses. 

With inheritance, unfortunately, comes several potential problems. The 
biggest problem is that of naming conflicts, which is when a class defines a method 
or attribute using the same name as an inherited one, either by choice, or by accident 
[Nels88]. Generally if this happens the inherited method/attribute is inaccessible in 
the new class. The problem becomes much more severe in languages that support 
multiple inheritance. For example, if there is a method X in class A and a method X 
in class B, and class C inherits from both A and B (see Figure 2.3), what happens to 
method X is very much language dependent [Mica88, Nels90a,NMO91]. A similar 
situation exists with the attribute q. 

One possible solution is to have the compiler check for name conflicts and 
flag them as errors, as in the language Eiffel [Meye88]. Eiffel does not permit a class 
to inherit a method with the same name from two or more parent classes. Any name 
conflicts must be resolved through the use of the redefine or rename commands 
when declaring the subclass [Meye88]. However, this requires the programmer to 
have some knowledge of the inner workings of the classes in the inheritance 
hierarchy, which violates the concept of encapsulation. An alternative notion to this 
is the super construct in languages such as Extended Smalltalk or CommonObjects 
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Figure 2.3 Multiple Inheritance Problem 



[Mica88]. This allows programmers to formally declare which superclass to inherit 
a method from [Mica88]. 

A different approach is to create a precedence list to determine which class 
to inherit from. A precedence list is a list that is established, either by the language 
or by the programmer to determine which classes are ‘senior’ to other classes. This 
precedence list can be generated in a number of ways. One way is through a depth- 
first traversal of the inheritance subgraph starting with the class in question. This is 
the approach taken in the languages Flavors and Loops. Another way to create the 
precedence graph is by using a programmer-defined precedence algorithm that 
resides in the metaclass of the class being defined. This is the approach taken in 
languages such as CommonLoops. [Mica88] 

Inheritance allows the programmer to define objects as they relate to other 
objects in their world view. Consider the example of an employee database. One of 
the classes that needs to be defined is Employee. This class could have attributes for 
name, age, sex, birthday, and address (see Figure 2.4). If the company has salaried 
and hourly employees, you could create separate classes for these. Salaried would 
have the attributes salary', years_of_service, job_title. Hourly would have the 
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attributes hourly_wage, position. Since both Hourly and Salaried are kinds of 
Employees, they both inherit from the class Employee. 




Figure 2.4 Employee Example 



Objects of type Hourly, for example, would have the inherited attributes 
name, age, sex, birthday, and address, along with the locally defined hourIy_wage 
and position attributes. Objects of type Salaried would have the same inherited 
attributes as Hourly, along with the locally defined attributes salary, 
years_of_service, and jobjitle. Thus, the subclasses of Employee have access to 
the attributes defined in the superclass as well as those in their own local definition 
(see Figure 2.5). 

Along with attributes, methods are also inherited by subclasses. An 
example might be add_new_employee, which could be defined in the class 
Employee. If the programmer wants to create a method for making a new hourly 
employee, he writes the method add_hourly_employee in the class Hourly. This 
method could first call add_new_employee which would return an instance of class 
Employee, then it would add the specific values for an hourly employee. The call to 
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Class Hourly 

Attributes (inherited): name, 
age, sex, birthday, address 
Attributes (local): hourly_wage, 
position 

Methods (inherited): 
add_new_employee 
Methods (local): none 



Class Salaried 

Attributes (inherited): name, 
age, sex, birthday, address 
Attributes (local): salary, 

years_of_service, job_title 
Methods (inherited): 
add_new_emp!oyee 
Methods (local): none 



Figure 2.5 Hourly and Salaried Attributes and Methods 

add_ne\\’ _employee would look inside the class Hourly for a method called 
add_new_employee , since it does not exist there it would look to the superclass for 
a method with that name. Since it is there it would execute; if not found there, then 
the entire inheritance hierarchy would be searched until the method is found or the 
top level of the class hierarchy is reached, which would result in an error condition. 

3. Encapsulation 

Encapsulation can be defined as “the process of hiding all of the details of 
an object that do not contribute to its essential characteristics” [Booc91; page 46]. It 
is also referred to as data hiding. In OOP, the user of a class should only need to 
know how to call a method and what methods are available to manipulate an object. 
The user does not need to know the internal details about how a specific method 
works, or what attributes the object has. All the user needs to be aware of is what 
message is passed to an object, and what will be returned by the object. 

Encapsulation is an important concept related to object-oriented 
programming and modularity of code. If the details of objects are hidden (i.e., they 
are encapsulated), then program developers can specify what they want and how it 
should interface; objects can then be built to specification without requiring 
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information about the exact structure of the object or how its methods are 
implemented. It also allows for the code to be improved/modified without affecting 
how end users access the object. 

One language that supports the idea of encapsulation is C++. The way to 
fully encapsulate attributes or methods in C++ is by declaring them as private, 
which means that they are only visible to methods of that class. Thus the 
implementation details are known only to the class that declared them. The external 
interface of the class could then be declared as public (visible to everyone). 
Additionally, C++ offers another alternative: declaring attributes/methods as 
protected, which means that they are visible only to the class and its descendants. 
By limiting the visibility of methods and attributes, encapsulation can be preserved. 
Most OOPLs provide some means of encapsulation; however, in many cases it is up 
to the programmer whether or not to utilize encapsulation. 

4. Reusability 

Reusability refers to “the ability of a system to be reused, in whole or in 
part, for the construction of new systems” [Mica88, page 13]. This is a very 
important issue in OOP, as one of the goals of OOP is to reduce the costs associated 
with software development and maintenance. If programmers develop commonly 
used structures such as hash tables, sorting algorithms, etc., and then test them 
thoroughly to prove their correctness, why should they be re-written each time they 
are required [Mica88]7 This should not be necessary if the code exists and can be 

reused without modification 3 . If the code cannot be reused as is, then perhaps it can 
be used as a superclass, and the subclass that inherits from it can make modifications 
or additions to the methods/attributes that are inherited. 

3. The idea of retesting methods is also addressed in [PK90]. It is pointed out that even though a 
method may be thoroughly tested in its original context retesting is required to meet the standards 
of adequate testing in the new context in which it appears. 
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Inheritance then becomes a key factor in determining how reusable a 
system is, because without inheritance the designers of software must either modify 
an existing class to do what is desired, or copy it and then modify the copy. Both of 
these alternatives are, however, unacceptable. The problem with modifying the 
original is the loss of abstraction. The original class may become unrecognizable as 
each programmer makes his changes. It may also become unusable to some clients 
because the details that were modified were ones that they relied upon. The problem 
with making a copy of the original class and then modifying it is the same type of 
problem associated with maintaining multiple copies of data. Each time the original 
class needs to be updated for bug fixes or enhancements, all copies of the class also 
need to be updated. Inheritance allows the original implementation of the class to 
stand as is, and clients can then use it or inherit from it and modify attributes or 
methods as required. 

Of course, with every benefit there are also drawbacks or side-effects 
associated with it. The side-effect associated with inheritance as it relates to 
reusability, is that if a class is properly encapsulated, then the subclass cannot 
modify the existing attributes or methods without violating that encapsulation. If, on 
the other hand, the subclass is created to simply take advantage of all (or some) 
features of the superclass and add some new functionality, then there is no problem 
with encapsulation. 

5. Polymorphism 

The ability to have more than one class with methods of the same name but 
with different implementations is known as polymorphism [Nels90a]. 
“Polymorphism is an important feature of all object-oriented programming 
languages that allows the definition of flexible software elements amenable to 
extension and reuse” [Mica88, page 31]. Examples of polymorphism (also called 
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operator overloading) that are common in most conventional languages are the 
arithmetic operators and /. If you declare two integers and two real numbers, 
and then perform addition on each pair, you have used the symbol *+’ to perform 
two different functions; one is integer addition and the other is floating point 
addition. 

Simple polymorphism refers to the ability of different classes to implement 
the same operation, differently. Multiple polymorphism is when a single class can 
have multiple operations with the same name, but possibly a different parameter list. 
When a message is sent to a class with multiple methods with the same name, the 
method used is determined by the parameters passed in the message. [Nels90a] 

Polymorphism allows programmers to add multiple methods to classes that 
share some commonality and therefore use the same name to denote the specific 
function. This is preferred over creating an artificial name to distinguish two or more 
methods that are essentially the same with the exception of their parameters, or the 
receivers of the message. An excellent example is a print method for a screen object 
and a printer object. If the receiver of the print message is a screen object the 
information will be displayed upon the screen, if it is a printer object the information 
to be printed will be sent to the printer. There is no distinction between the messages 
to perform a screen print and printer print, however the result of the method is very 
different. 

B. DATABASE MANAGEMENT SYSTEMS 

Of the three major topics covered in this chapter, databases and database tech- 
nology is the oldest. It is also a major part of the foundation upon which this thesis 
is built. This section serves as an overview of database topics and the distinctions 
between the different types of database technology available in the marketplace to- 
day. It is not intended to be a tutorial for novices to learn database systems. The read- 
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er may refer to “Fundamentals of Database Systems” by Ramez Elmasri and Sham- 
kant B. Navathe [ER89] for a more detailed introduction to this subject. 

1. Basic Terminology 

A database is a logical collection of related data that has some intrinsic 

meaning [EN89]. It can also be defined as data that is permanently 4 stored in a 
computer [Nels90b]. These definitions lead to the conclusion that a random 
collection of data is not a database, which is an accurate assessment. A database is 
also said to represent a subset of the real world, sometimes called a miniworld 
[EN89]. 

The tool used to build, store, and manipulate the data stored in a database 
is the database management system (DBMS). A DBMS can be thought of as a 
general-purpose software system [EN89] to perform the previously mentioned 

tasks. Each type of DBMS (hierarchical, network, relational, and object-oriented) 5 
has its own particular way to define the data being stored; this is sometimes referred 
to as its data-definition language (DDL). The way a DBMS stores and retrieves data 
from the storage medium (disks, tapes, etc.) is through its storage definition 
language and the way a database user sees the data presented is controlled by the 
view definition language. Some DBMSs have these languages separated into 
distinct languages while others have a single all-purpose database programming 
language. 

Another important concept in database technology is the data model, kdata 
model is a way to abstract the data being stored in a database to provide a clearer 
visualization of the data than computer storage concepts provide. That is, data 



4. That is, the data will exist after normal termination of the program. The data is “permanent’* until 
the user issues a delete command to remove the data from the database. 

5. Only relational and object-oriented approaches are discussed in detail in this thesis. 
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models represent the data being stored in a form that is more meaningful to the user 
than the actual form the data takes on the storage medium. For example, consider a 
data model that represents the data in a tabular form. This would be clearer to most 
people than a B-Tree data structure that might actually hold the data. 

Many different types of data models exist to represent the different types of 
databases. One model that crosses the boundaries of different database types is the 
entity-relationship (ER) model [EN89]. This model can be used to design a 
relational database as easily as a hierarchical, network, or object-oriented database. 
The basic elements of the ER model are entities, attributes, and the relationships 
between entities. An entity is defined as a “thing” in the real world, either tangible 
(e.g., an employee) or intangible (e.g., a project) and each entity has attributes that 
describe it. For example, an employee object might have attributes representing 
name, dept, social security number, etc. A relationship between two entities means 
that they are linked by some attribute in each entity. Relationships can represent one- 
to-one, one-to-many, or many-to-many associations between relations. An example 
is a company database that maintains employee entities and project entities. A 
typical relationship might be a ‘works-on’ relationship where employees work-on a 
project. An attribute of an employee entity might be project number and an 
attribute of project might be number. The works-on relationship would consist of 
tuples representing every employee/project pair. Quite often the relationship is 
stored in the database as a table as well because they have attributes associated with 
instances of the relationship, or because the relationship is one-to-many, or many- 
to-many. 

2. Relational Databases 

The relational data model was introduced in 1970 by Dr. E. F. Codd 
[Codd70], Since its introduction there has been a great deal of interest in, and 
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development of, relational database systems. This can be attributed to the ease of use 
associated with it as well as its firm mathematical foundation. It is also a more 
abstract way to present a database than hierarchical or network databases, which are 
closely tied to the physical data structures. 

A relational database is, as the name implies, a collection of relations. 
Relations can be thought of quite simply as tables containing entries for each entity 
being stored [Alag86]. These tables consist of many instances (or rows) of tuples, 
and a tuple (often called a record) is a collection of related data that describes one 
entity of an ER diagram, or one object being stored. The columns of a relation 
represent the attributes associated with an entity in the ER diagram. 

The key to understanding relational databases lies in understanding set 
theory from mathematics. The concept of storing data in tables is fairly easy for the 

average individual to comprehend. Figure 2.6 6 is an example of a very simple 
relational database displayed in tabular form. One would have to agree that there is 
little difficulty in determining what is being stored in this database. However, 
understanding how to obtain specific records or values from the database requires 
that the user understand the relational algebra associated with performing queries. A 
query, as the name implies, is how a database is interrogated or probed for 
information. Queries are performed to retrieve specific information from the 
database. For example, to obtain a list of employee names whose SupSSN is equal 
to 222333444 requires two select operations and a project operation. These 
relational operations, plus union, set difference, and Cartesian product, are the 
subject of the following section. 



6. The name of the primary key is underlined. 
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Employee 



Name 


SSN 


Dept 


Smith 


123456789 


Sales 


Borg 


222333444 


Mktg 


Jones 


256789043 


Sales 


Williams 


456782910 


Sales 


Edwards 


598320982 


Mktg 



Department 



dept-name 


Location 


SupSSN 


Mktg 


New York 


222333444 


Sales 


Los Angeles 


256789043 



Figure 2.6 Simple Relational Database 



a. Relational Algebra 

One of the most commonly used relational operations is the select 
operation. This operation is used to retrieve entire tuples from a relation. The select 
operation gets the tuples based on a selection condition. The selection condition is 
a boolean expression made up of one or more expressions of the following form: 
<attribute name> comparison operator> constant value>; or 
<attribute name> comparison operaton> <attribute name> 
where <attribute name> represents an attribute name in the relation being operated 
on, comparison operator> is one of the operations in the set (<, >, =, <, >, ^ ) , and 
constant value> represents a constant value. There can be any number of these 
clauses joined by the Boolean operators AND, OR, or NOT. [EN89] 

The project operation is similar to the select operation except that 
where the select operation retrieves specific rows from a relation, the project 
operation retrieves entire columns from a relation. Also, instead of a selection 
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condition to determine which tuples to chose, the project operation simply lists the 
attribute names or the columns to be retrieved. [EN89] 

The next three relational operations can be classified as Set Theoretic 
Operations . That is, they are operations that are performed on entire sets (relations). 
The basis and proof of correctness of these operations is directly related to 
mathematical set theory proofs and concepts. [EN89] 

The union operation creates, from two union compatible relations, a 
new relation that contains every tuple from both of the original relations with 
duplicate tuples removed, just like the union of two sets in mathematics. Union 
compatible means that both relations have the same number of attributes and the 
attributes are of the same domain (e.g., the attribute pairs are both from the set of 9 
digit integers). Figure 2.7 shows two union compatible relations, the Employee and 
Supervisor relations, and Figure 2.8 is an example of the union of those relations. 



Employee Supervisor 



SName 


SSSN 


Borg 


222333444 


Stone 


567811543 



EName 


ESSN 


Smith 


123456789 


Borg 


222333444 


Jones 


256789043 


Williams 


456782910 


Edwards 


598320982 



Figure 2.7 Two Union Compatible Relations 

The set difference operation is defined as the relation containing all the 
tuples in the first relation but not in the second, as in Figure 2.9. It is denoted by a 
minus sign (“-”) such as Employee - Supervisor. 
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Figure 2.8 Result of Employee Union Supervisors 
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Figure 2.9 Result of Employee - Supervisor 

The Cartesian product operation combines tuples from each relation in 
such a way that each tuple of the first relation has each instance of a tuple from the 
second relation appended to it. The resulting relation has as many attributes 
(columns) as both relations combined and the number of tuples is equal to the 
number of tuples in the first relation multiplied by the number of tuples in the second 
relation. The Cartesian product of the relations Employee and Department is shown 
in Figure 2.10. 

As can be seen in Figure 2.10, there is quite a bit of redundancy in the 
resulting tuples as each tuple in the first relation is repeated once for each tuple in 
the second relation and vice versa. Therefore, the result of a Cartesian product is 
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Figure 2.10 Result of Cartesian Product of Employee with Department 

usually used only for a specific purpose and then discarded due to this excessive 
redundancy. 

The five relational operations just covered have been demonstrated to 
be a complete set of relational algebra operations [EN89]. That is, it has been shown 
that any other relational operation can be constructed from some combination of 
these five basic operations. Thus any relational database system can be considered 

complete if these five operations are included 7 . 

b. Limitations of Relational Databases 

Probably the most obvious and important limitation of conventional 
databases (i.e., relational as well as hierarchical and network) is the lack of support 
for large unstructured data such as sounds or pictures. As Kim points out in [Kim91], 
conventional databases have served us well in the application domain they were 

7. Of course, efficiency of operations is another issue. For instance, it may be much more efficient 
to implement other operations, such as intersection, directly rather than in terms of these five basic 
operations. [Nels88] 
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originally developed for, namely business and payroll type applications. However, 
many of today’s applications, including CASE tools and CAD programs, require a 
more dynamic storage and retrieval system such as the object-oriented data model. 

Additionally, relational databases tend to loose the structure of the data 
being modeled as it is normalized. To efficiently model data in the relational model 
it must be normalized, or flattened out to remove redundancies and dependencies. 
In doing so the original structure of the data is often lost. This causes the data 
abstraction to be lost and removes much of the original meaning of the entity being 
stored. 



3. Object-Oriented Databases 

In recent years there have been quite a few object-oriented database 
management systems (OODBMS) developed. This section briefly describes some 
features common in most OODBMS as well as discussing various problems and 
limitations associated with them. Two example OODBMSs to be discussed herein 
are Gemstone [Serv89a, Serv89b] and Vbase [Onto88] (the predecessor of Ontos 
[Onto90]). 

What differentiates an OOPL from an OODBMS is persistence of objects. 
An OODBMS allows the user to create and manipulate objects (as does an OOPL), 
but it also provides for permanent storage of the object so it can be used again in 
another session. Most OOPLs do not have the facilities to save objects from one 

session to another 8 . Aside from this difference most OODBMSs are very similar to 
OOPLs. 

OODBMSs allow users to declare classes and create instances of these 
classes just as OOPLs do. However, when the user requires an object that has been 

8. It should be noted that Prograph is one of the few OOPLs that does support object persistence 
without requiring a database file to hold the objects. This feature will not be used for the purposes 
of this thesis, a separate database file will be created instead. 
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written to secondary storage, the OODBMS retrieves the object from the storage 
medium and puts it into the correct form so that the user can manipulate it. An OOPL 
can only retrieve objects stored in memory during a single session. The OODBMS 
handles the reading and writing of the objects to and from the storage medium in a 
way that is transparent to the user, just like conventional DBMSs. However, 
OODBMSs also maintain the methods associated with the class of the object being 
stored so they retain their ability to function and perform operations. Conventional 
databases store only data values and therefore they can only be used by a separate 
program; objects stored in an OODBMS, on the other hand, are able to function 
when they are retrieved from the database. 

All OODBMSs surveyed have a database programming language 
associated with them as well as a class library. There are as many languages as there 
are systems. Some languages are variants of Smalltalk-80 (e.g.. Opal, the Gemstone 
data definition and manipulation language), others are variants of C or CLU (e.g., 
COP, the data manipulation language of Vbase). There are also many different class 
libraries which contain class definitions for such classes as Collection, Set, 
Dictionary, Association, and others. These classes provide a means to organize the 
objects being stored in the database. Without these classes an OODBMS would not 
be very usable, it would merely store all objects in one location without a logical 
connection and, as discussed earlier, this defies the definition of a database. 

When creating objects, the user will generally chose to store each object in 
a collection of some kind based upon the type of data/database being modeled. If, 
for example, the user wishes to model a relation, an instance (or descendant) of Set 
might be created, because relations are defined as sets of related tuples. By storing 
objects within a descendant of Collection the data can be thought of as one logical 
unit and manipulated as such. Depending upon the subclass of collection being used, 
the data being stored can also inherit qualities that provide easier (or faster) access 
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to each object. For example, if a collection of objects is related in such a way that 
the objects are all different and each has a key/value associated with it, an instance 
of Dictionary might be created to hold the objects. [FN92a] 

OODBMSs also provide many of the features expected in conventional 
database systems, such as access control and concurrency control. They generally 
provide methods for locking individual records/objects during updates, just like 
conventional databases. Since the OODBMSs surveyed are designed to run on 
multi-processing architectures, concurrency control is built into the database kernel 
or monitor running on the host computer. 

It has been said that relational databases are value-based whereas object- 
oriented databases are identity-based [ZM90]. This is a result of the previously 
discussed idea that object-oriented databases capture the function as well as the 
value of each object. 

4. Relational/Object-Oriented Databases 

Although there has been relatively little work done in this area of database 
research, it is probably one of the more important areas. This is because there exists 
a very large base of relational database applications, and SQL-based languages have 
become the defacto industry standard [Alag86]. While most agree that object- 
oriented databases are the way of the future, many hours and dollars have been 
invested in relational systems and people are generally unwilling to forsake 
relational databases in favor of a new model. What the relational/object-oriented 
model promises is a way to have all the benefits of the newer 00 approach without 
abandoning the “tried and true” relational approach. 

It has already been established that a major failing of conventional 
relational databases is the inability to represent complex data types. This is very 
important if technology is to continue to move forward. A relational/object-oriented 
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database system would take the best of both types of database technology and 
combine them into a single more powerful database tool. 

It has been proposed that the capability to perform relational operations 
could be added to any object-oriented system [Nels88, NMO90]. A prototype 
system, called a relational object-oriented database management system (ROOMS), 
provides an interface that could be used as a stand alone database system or added 
to any existing OODBMS. The system is designed around a Relation class, a 
Record class, and a Database class. The workhorse is the Relation class. It includes 
of methods for each of the five basic relational algebra operations as well as methods 
to display a relation and add/delete records from the relation. This approach will be 
discussed in more detail in the next chapter. 

C. PROGRAPH 

Prograph [TGS88a, TGS88b, TGS91] is billed as a “Very high-level pictorial 
object-oriented programming environment” for the Apple Macintosh. This means 
that the level of abstraction from machine language is about as distant as one can get 
(at this time, anyway). For example, programs written in assembly language are di- 
rectly tied to a specific processor, and the actual instructions have a nearly one-to- 
one mapping with the machine instructions for that specific processor. In contrast, 
Prograph allows the programmer to design and implement programs as a number of 
objects which interact with one another to produce desired results. This is common 
to all OOPLs; however. Prograph allows the programmer’s mental image to be 
transferred to the computer in an iconic fashion, thereby reducing loss in translation 
to textual form. To aid the programmer in seeing the application in terms of classes, 
methods, and attributes, Prograph makes use of both icons and the Macintosh oper- 
ating system’s windowing environment. Programs are built as dataflow diagrams 
representing the data that flows through the program. This is in contrast to traditional 
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programming languages which treat data as something stored away in memory 
somewhere, and only handled as necessary. 

Prograph is a hybrid OOP language. This is because Prograph supports primi- 
tive language types such as character, integer, boolean, etc. A pure OOP language 
has no primitive language types; everything is an object [Booc91, Mica88]. 
Prograph, like C++, has primitive data types as part of the language that are not in 
the inheritance hierarchy. Another feature that makes Prograph a hybrid language is 
the concept of universal methods. These are methods that do not belong to any par- 
ticular class, but can be called from any method in any class [TGS88b]. Support for 
universal methods frees the programmer from having to create specialized classes 
somewhere in the inheritance hierarchy to perform one specific task. 

1. The Language 

Since Prograph is a dataflow language, data is active, not static. That is, data 
moves through the program rather than sitting in a memory location waiting to be 
processed as in the von Neumann model. In a dataflow language, as soon as data is 
available to each input of an instruction, it can execute. This represents a key 
difference between dataflow languages and sequential text-based languages, in that 
the execution of a von Neumann machine is based on the process of fetching an 
instruction, executing it, and then fetching the next instruction, and so on. This 
provides a single thread of control from instruction to instruction. In contrast, the 
dataflow machine’s instruction cycle detects when all required inputs are active (i.e., 
have data available), fetches the instruction, executes it, and generates the data to be 
output by the instruction. Since there are many possible flows of control in a 
Prograph program, it supports concurrent processing [TGS88a]. Obviously, since 
the programs used in this thesis are intended to be run on a uniprocessor system (the 
Apple Macintosh), true concurrency is not possible. 
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Some additional Prograph terminology is necessary to understand the 
examples used herein: terminals, roots, and primitives. Terminals are the input to 
methods and primitives, and roots are the outputs. Primitives are the procedures (or 
functions) that are built into the language. 

An example of a primitive is get-file. This primitive accepts as input (via its 
single terminal) a list of file types to be displayed in a standard Macintosh open file 
dialog box (see Figure 2.11). The outputs of this operation are: the name of the file 
selected from the scrolling list, the volume identifier, and the file type. This is just 
one example of the power of primitives. They encapsulate much of the detail 
involved in creating certain displays, as well as performing such functions as 
arithmetic, list processing, and so on. 
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Figure 2.11 Result of get-file primitive 

Prograph is one of the few OOPLs that supports persistent objects. 
Persistents are defined as data or objects that exists from one execution of a program 
to another. They are created and displayed in a Persistents window that is separate 
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from the Classes window and the Universal window. Persistents are created in the 
same way as a class or method, and can be double-clicked to display their values. 
Persistents allow the user to manipulate objects and store them within the program 
so that they can be used later during the execution of the program, or recalled during 
another execution of the program. 

a. Classes 

Prograph classes are represented by hexagonal icons displayed in the 

Classes window (see Figure 2.12 9 ). Within the window are the class hierarchies for 
the program. There can be as many separate hierarchies as the application requires. 
This is different from some other languages, such as Smalltalk, which allow only a 
single class hierarchy. In Figure 2.12 there are three distinct hierarchies. Two of 
them contain only one class each and the third has as its root the class Animal. The 
lines between classes in the Animals hierarchy represent the inheritance links 
between various classes. 

The class icon itself represents the component parts of a class, its 
attributes, and its methods. The left-half of the icon represents the attributes of the 
class, the right-half represents the methods. Double-clicking on the left half opens 
the attributes window for the particular class. Similarly, double-clicking the right 
half opens the methods window for the class. 

To create a new class the programmer points to white space in the 
Classes window and clicks the mouse button. Once the icon appears the programmer 
gives the class a name and defines its attributes and methods. If the name selected 
by the programmer already exists, then the system will not accept it, warning the 
user that the chosen name is already in use. 

9. This figure as well as those that follow in this section, are taken from an example in Part II, Chap- 
ter Six of the Prograph Tutorials [TGS88a], 



29 




Figure 2.12 Barnyard Simulator Classes Window 
b. Attributes 

Attributes are displayed in the attributes window. Class attributes are 
represented by the hexagon shaped icons, and instance attributes are represented by 
inverted triangles. The attributes window is divided into two parts by a horizontal 
line. Above the line are class attributes, below it are instance attributes. The attribute 
windows for the classes Animal and Guernsey are shown in Figure 2.13. The class 
Animal has no class attributes, only instance attributes which are defined locally. 
We know this because the icons for the attributes do not contain a downward 
pointing arrow. In contrast, the attribute window for Guernsey has one class 
attribute, herdMembers which appears above the horizontal line, and instance 
attributes name, age, and food, below the line. The three instance attributes are all 
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Figure 2.13 Sample Attribute Windows 

inherited via the superclass Cow 10 . This is shown by the downward arrow in each 
instance attribute icon (inverted triangle icon). If there were any attributes particular 
to only a Guernsey, they would appear below the inherited attributes in the window. 
The class attribute is also inherited from Cow so it has the downward arrow in the 
icon (the hexagonal icon). 

Attributes can be assigned initial values by double-clicking on the icon 
and changing the value in the attribute editor. Attributes can also be more than 
simple data types, they can be instances of other classes; this is how you represent a 
composite object in Prograph. 



10. Any attributes inherited by Cow are also passed on to its subclasses. 
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c. Methods 

Methods are represented by an icon that contains a mini-dataflow 
diagram (see Figure 2.14). The hexagon shaped icon labeled <o> is a special kind 
of method called an initialization method or instance generator. This instance 
generator method is invoked whenever an instance of that class is created. It allows 
you to tailor creations of an instance. This method also overshadows the instance 
primitive ( overshadowing is the term used in Prograph for redefining inherited 
attributes/methods). 
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Figure 2.14 Class methods window 

When a method is selected and opened (by double-clicking the icon), a 
case window such as the one in Figure 2.15 is opened. This is where the dataflow 
aspect of the Prograph language is most apparent. In this example, there are three 
basic types of operators. The operators with the concave left side labeled food, 
name, and what happened are Get operators. These retrieve the values of the 
attributes that match their label. Operators with a convex left-side (such as the 
bottom occurrence of what happened) are Set operators. These set the values of the 
attributes that match their label. The other types of operators shown are primitives. 
For instance, the two labeled join catenate two or more strings to produce a single 
string. The long narrow bars at the top and bottom of the case window are the input 
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bar and the output bar. These are where the data flowing in and out of the method 
are attached. In this example, there are two inputs (an instance of the class Animal, 
and the current eventRecord) to the method, but no outputs. 
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Figure 2.15 Case Window for Animal/eat 



d. Message Passing 

Message passing in Prograph is accomplished by creating a simple 
operation with the name of the method being called. Once the method has been 
named and the Enter key (Return key) has been pressed, Prograph assigns the 
operation the correct arity based upon the arity of the method called. Arity refers to 
the correct number of terminals and roots for the operation. Figure 2.16 shows the 
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five ways to reference a method. They are, respectively: universal reference, explicit 
reference, data-determined, context-determined reference, and super. 
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Figure 2.16 Method References 



A universal reference is when the method being called resembles 
Example 1 of Figure 2.16; that is, there is no slash (“/”) preceding the name of the 
method. The method to be executed is located in the Universal methods window. 
Universal methods are similar to global functions in other programming languages, 
because they have a global scope. In an object-oriented language such as C++ these 
types of functions could be stored in a Global dictionary so they could be used by 
any method that needs them. 

An explicit reference is always in the form ClassName/MethodName 
(see Example 2 of Figure 2.16). If the method is not found in the specified class, its 
ancestors are examined for the appropriate method name, but the search begins with 
the class named before the slash. These types of methods are not directly related to 
any object-oriented concept. They are provided mainly as a way of supporting 
traditional programming concepts. 

A data-determined reference is similar to the 00 concept of message 
passing and is denoted by a method name preceded by a slash (see Example 3 of 
Figure 2.16). The method called is based upon the instance of the data arriving on 
the left-most terminal of the operation. In other words, the class to search for the 
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named method is the same class as the instance arriving on the left-most terminal. 
Data-determined references are examples of single polymorphism. 

A context-determined reference is akin to the 00 concept of sending 
a message to one’s self and is denoted by the method name preceded by two slashes 
(see Example 4 of Figure 2.16). The class to be examined for the named method is 
the same class the calling operation exists in. For example, a class Cow might 
contain a method new_cow that creates a new instance of the class Cow and names 
the new instance by calling the method name in class Cow. The operation in 
new’jcow that names the new cow is labelled //name, this tells Prograph to look for 
name within this particular class. 

The fifth type of operation is called super. It is a context-determined 
reference that searches for the appropriate method, not in the class it is called from, 
but its superclass. A super operation is denoted by an up-arrow in the right side of 
the operation icon (see Example 5 of Figure 2.16). The super operations allow a 
method to use a parent’s method and then add its own functionality to the parent’s 
method. 

e. Control Structures 

Even though Prograph is a dataflow language, flow control can be 
imposed and is in fact often necessary to obtain desired results. The primary way to 
affect the program flow is through the use of controls. Controls are attached to 
certain operations and are activated based upon success or failure of the operation. 
The default setting for all operations is to activate on success. This default is 
changed by selecting the operation desired and selecting the appropriate control 
from the Controls menu. 

Controls are represented by a small square icon attached to the right 
side of an operation. Within the square is a check mark (V), indicating activate on 
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success, or an X, indicating activate on failure. There are also other icons within the 
small square indicating what action to take if control is activated (e.g., go to next 
case, continue, terminate, finish, or fail). Probably the most common control is the 
‘on failure go to next case’. This allows the programmer to execute different 
operations within a single method based upon success or failure of a test. This could 
be used as an if-then-else structure or a case structure. An example of an if-then-else 
structure is shown in Figure 2.17. The < operation has an ‘on success go to’ (V) 
control attached to it so if the age of the cow is < 3, control goes to the next case (i.e., 
Cow/name 2:2) and “Lil”’ is appended to the front of the cow’s name. If the age < 3 
operation fails, control remains in the current case and only the name of a cow is 
output. The case windows are distinguishable by their title bars. Each has the same 
method name, but they also have 1 :2 or 2:2 to distinguish the first case window from 
the second. A comparable C code fragment is shown in Figure 2.18. 




Figure 2.17 Control Structure Example 
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if (cow .age > 3) printf(“%c”,cow.name); 
else printf(“Lil’%c”,cow.name); 



Figure 2.18 Example C Code 

Another form of flow control is the synchro link. It forces one operation 
to be executed before the second can execute. This allows the programmer to ensure 
that two things which could be executed in either order, will only be executed in the 
desired sequence. In Figure 2.19, for example, there is a synchro link from show to 
ask. This is to ensure that the show operation executes before the ask operation. 
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Figure 2.19 Synchro Link Example 



Synchro links are a useful tool in controlling the execution of certain operations. 
However, they do not guarantee that the second method will follow immediately 
after the first; rather, it only guarantees that the first operation will execute before 
the second. 
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2. Prograph Database Engine 

Before discussing the Prograph database engine, it is appropriate to first 
define some new terms. The Database Engine is the set of primitives which perform 
all of the functions normally associated with a database management system, 
including all the functions necessary to create and maintain a disk-based database. 
These primitives allow the programmer to manipulate databases, the tables stored in 
the databases, and the clusters that make up the tables. The programmer can also 
access the keys for a database table through primitives. Tables in Prograph databases 
are composed of clusters which should logically be of the same type (i.e., all the 
clusters should be an instance of a single class), but are not limited to this 
convention. In its simplest form, a table represents data that the programmer has 
grouped together. A Cluster represents the individual record being stored in the 
database. The cluster is not restricted to any specific data types. “A cluster can 
contain textual, numeric, and boolean (TRUE or FALSE) data, as well as Macintosh 
structures (such as PICTs or ICONs) and Prograph objects (instances of classes)” 
[TGS91, page 48]. A cluster is a way of taking an arbitrary collection of Prograph 
objects and packing them into a single stream of bytes. The breaking up of objects 
into clusters is transparent to the user; the user always sees the cluster as a collection 
of data.The database engine allows the programmer the flexibility to model flat-file, 
relational, object-oriented, and other databases as the programmer deems necessary. 
[TGS91] 

A database can be accessed in one of three modes: query, update, or shared 
mode; with the mode being determined when the database file is opened. Query 
mode allows read-only access to a database by multiple users. Update mode is for 
single-user reads and writes to a database. The share mode provides multiple users 
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both read and write access to the database. 11 In the multiple user modes, all users 
must open the database in the same mode (i.e., all users must be in either query 
mode, or they must all be in share mode, but not a mixture of query and share). 

Access to the data stored in the database can be through one of three access 

methods: direct cluster access, sequential key access, and random key access. 

Direct cluster access means retrieving a cluster based upon its ID (each cluster has 
a unique ID which corresponds to the byte offset of the cluster in the data file). 
Sequential key access is the way clusters are retrieved based upon the ordering 
imposed by the value of the key. For example, if the clusters were employee entries 
and the key was last name, sequential key access would allow retrieval of employees 
in alphabetical order. Random key access is how clusters are retrieved based upon 
key /value matches. Suppose the employee record desired has the last name equal to 
Smith; random key access allows the cluster corresponding to the key value equal to 
Smith to be retrieved without having to visit all the intervening records first. 

Prograph databases can contain multiple tables, and each table can contain 
multiple clusters and multiple keys. In order to manipulate a cluster (record) in a 
Prograph database, the programmer must first open the database file, then the tables, 
and finally the keys (if applicable). This hierarchy must be adhered to or the 
primitives associated with storing and retrieving clusters will fail and return an error 
code that must be handled by the application. 

All database primitives (i.e., database, table, key, and cluster primitives) 
return as the left-most root an error code. If the error is a zero (0), the operation was 
successful; if it is any other integer, then there was an error. This allows the program 
to recover from errors by testing this output and branching as appropriate. It also 

1 1 . Multiple users refers to the ability to share a database across a network of Macintosh computers. 

The database would reside on a File Server and the clients could access the data concurrently. 

12. These are access methods in the classic database sense, not as in object-oriented methods. 
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allows the program to close all open database files in the event of an unrecoverable 
error such as a “Disk Full” error. 
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III. WHY AN R/OODBMS 



The previous chapters were presented to give the reader a basic understanding 
of OOP, Prograph, relational databases, and object-oriented databases, and to act as 
a common point of reference for ideas presented in this chapter and the next. This 
chapter presents a discussion of some of the deficiencies associated in current 
database systems. There is also a discussion of why a relational/object-oriented 
approach is advocated and why this approach is taken. Finally, the reasons for 
selecting Prograph as the language to implement these ideas are covered. 

A. DEFICIENCIES IN CURRENT DATABASE SYSTEMS 

This section covers the problems associated with building complex database 
applications using existing database systems. The desired properties of each type of 
system are also presented. 

1. Relational Databases 

Relational database technology and its limitations are the driving force 
behind this thesis. Current implementations of the relational data model are very 
limited in their ability to handle complex data types. That is not to say that the 
relational model is no longer of value, as it still serves the purposes of many 
applications quite well. As discussed in the previous chapter, however, the relational 
databases that are currently available do not allow users to maintain the desired level 
of abstraction and encapsulation of the data being stored and manipulated. 

a. Limited Number of Data Types 

The number of data types available is typically fixed in RDBMSs, and 
is one area of concern for developers of new types of database applications. 
Specifically, the lack of support for complex data types such as digitized pictures, 
digitized sound, and composite objects. Some relational databases currently 



41 



available have the capability to store pictures in a database, but not sounds or 
composite objects, and there is no way to perform a query based on a complex 
object. In a CAD application, it is desirable not only to be able to store graphical 
objects, but also to be able to perform queries based upon them. The ability to 
display graphical objects based upon their properties is also very desirable. 

All relational databases include support for simple data types (i.e., 
strings, numerical, boolean, etc.), and some even provide support for digitized 
pictures. However, the real world we wish to model is much more complex than this. 
The world we are attempting to model may include animated graphical objects, 
sounds, and composite objects, just to name a few. There is currently no relational 
database system that provides support for complex data types such as these. 
However, it should be noted that some relational database systems do support free 
form attributes, often called memos. These memo attributes are basically free form 
text fields of arbitrary length, so they could be used as a pseudo-repeating field. 
Also, as previously mentioned, some relational systems provide support for picture 
objects, but they are limited in their functionality. 

b. Loss of Abstraction 

To correctly model data to be stored in a relational database, there must 
be some form of decomposition of real world objects into flat objects. Occasionally, 
certain contrived relations must be created to achieve a satisfactory level of 
normalization. An example of this is a company database that contains employees, 
dependents, and possibly several other entities. Since Dependents is a weak entity 
related to an Employee entity, a possible method for implementing this relationship 
is to create a separate relation for each entity. In other words, create one relation to 
store instances of Employees, and another for instances of Dependents. This is an 
awkward way to model this real world relationship because Dependents have little 
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to do with the company database. A more appropriate way to model this relation and 
store the data would be with a multi-valued attribute of Employee; however, multi- 
valued attributes are typically not supported by RDBMSs. The attribute of 
Employee, call it Dependents, would store multiple instances of dependent entities. 
By storing the entities as an attribute, there would be immediate access to the 
dependant information whenever an employee object is retrieved. 

To model this relationship in most RDBMSs requires two separate 
relations, an employee relation to hold instances of employees, and a dependent 
relation to hold instances of dependents. This greatly reduces the level of 
abstraction, and in some complex systems adds to the level of confusion. It also 
requires fairly complex algebra to retrieve some information. For example, if a user 
wishes to retrieve a list of Dependents for each female employee, five relational 
algebra statements are required. In the previous approach, only two are required, a 
selection of all female employees and a projection of the Dependents attribute. 

c. Tuples Lack Function 

It is attribute values that are stored in a relational database. While this 
is good for many bookkeeping applications, it is not desirable for many graphics 
based applications. In the average relational database, displaying a tuple or specific 
attributes of the tuple is a simple task that can easily be done by the database system. 
This is because the values are simple ASCII text or numeric values. Displaying a 
graphical object is not as simple. Consider the example of a multi-media database 
that stores animated pictures and sounds as well as textual or numeric data. If the 
user wants to display the animation sequence, the object retrieved had better have a 
function called display to play the animation because a non-application specific 
DBMS will not have the ability to do this. Also, if the user wants to play the sound 
clip that is stored in the object, then there had better be a play-sound function 
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because the DBMS does not have this capability either. A display method could also 
be written to display different things based upon the user’s view of the object. This 
is not possible in a relational database because the information in the database does 
not carry any of the functions associated with the data. Therefore, current systems 
are only as good as the applications programs written for each specific application, 
as the data does not contain any information about how to handle itself. 

d. Lack of Inheritance 

Relational databases do not provide any means for defining attributes 
based upon previously defined attributes. Instead of being able to inherit previously 
defined attributes, the user must create new tables and new relationships between the 
tables to accomplish the same goal. For example, an employee database consists of 
employees who are all people. People all have the same general set of characteristics 
such as color hair, color eyes, name, age, etc. All of the employees, in addition to 
being people, are also members of a specialized group, such as hourly_employees 
or salaried_employees, with their own specific attributes. Using an object-oriented 
approach, each type of employee could be a descendent of the class People, and as 
such would have the characteristics previously mentioned. In a relational database, 
however, employee objects are represented as tuples in three different tables, one 
table contains all instances of people, another contains all instances of 
hourly_employees, and a third contains all salaried_employees. In an object- 
oriented approach there would only need to be two tables, one for hourly_employees 
and another for salaried_employees, because each type of employee would have all 
the attributes of people as well as the attributes specific to their class (i.e., hourly or 
salaried employees) 
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2. Object-Oriented Databases 

Although, OODBMSs are a step in the right direction for database 
technology, they lack certain features which make them inadequate for tomorrow’s 
applications. Specifically, the solid mathematical foundation and the standardization 
of the relational data model makes it a more attractive solution for many applications 
despite its limited modeling capabilities. If these deficiencies are overcome, there 
should be no reason why OODBMSs cannot gain the “lion’s share” of the database 
industry, especially if they include the capability to efficiently model relational 
databases. 

a. Lack of Mathematical Foundation 

Relational algebra operations can be proven to be complete and correct 
based upon mathematical set theory, whereas OODBMS operations cannot. This is 
because there is no core of operations that has been thoroughly tested and proven for 
OODBMSs. This is definitely a limiting factor in OODBMSs because users want to 
know that they are definitely going to get the correct answer when the database is 
queried. 

As previously mentioned, all relational operations can be built from the 
following operations: union, difference, projection, selection, and Cartesian 
product. These operations are based upon the ones developed by mathematicians, 
and can be combined to form all other types of relational operations. This provides 
the database user with a certain level of security as all operations conducted on a 
database are guaranteed to be correct and complete. 

b. Lack of Standardization 

The other major deficiency in current object-oriented databases is the 
lack of standardization of operations and class libraries, which is one of the strongest 
features of relational databases. Although each vendor’s version of a relational 
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database system may be different, the basic operations are all there and the systems 
are therefore functionally equivalent. Such a core of operations does not exist in 
object-oriented databases because object-oriented programming still lacks a formal 
definition. Consequently some vendors provide languages that they call object- 
oriented simply because they contain support for objects or abstract data types, but 

not inheritance 1 . Once an industry-wide standard is adopted, a core of features can 
be required for OOPLs as well as OODBMSs and standardization will not be an 
issue. 

All the OODBMSs surveyed for this thesis provide a class library, but 
each library is different. There is no standardization between systems, and one 
cannot count on all the classes used in one system to be available in the next. If there 
were a standard minimum set of operations required for all OODBMSs, and if it 
could be proven to be complete, then OODBMSs would almost certainly become 
more widely accepted. 

c. Lack of Support for Relational Operations 

This is understandable because object-oriented databases are not 
normally organized into logical relations. Object-oriented systems provide their 
users with a large storage area in which they can store any type of object. In the 
interest of compatibility and completeness, however, why not provide support for 
relational operations as part of the system? As this thesis points out, relational 
operations can be added to an object-oriented database, and in fact should be. 
Opponents of this idea might state that hierarchical and network databases are not 
currently supported, so why support relational? The answer to this is easy, they 
should all be supported [FN92]. The hierarchical data model lends itself to be easily 



1 . Systems supporting objects but not inheritance are more appropriately considered “object-based” 
[Wegn87], 
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integrated into an object-oriented database, and to a lesser extent so does the 
network. The flexibility of object-oriented languages and OODBMSs make it fairly 
easy to achieve this goal, but that is another issue. Compatibility with the relational 
model would definitely increase the credibility of OODBMSs. It would also open 
the door for developers to build relational systems for users in an OODBMS to allow 
for the future expansion of the database application as the needs of the customers 
change. 

3. Relational/Object-Oriented Management System 

The Relational Object-oriented Management System (ROOMS) as 
proposed in [Nels88, NMO90] is the model that this thesis is built upon. This 
system, however, lacks secondary storage features and this short-coming is the 
reason this thesis was written. The implementation proposed in this thesis adds the 
capability to store data to secondary storage, turning the ROOMS concept into a true 
database system. 

4. Desired Properties of Database Systems 

An extended relational system that could provide the ability to define 
complex data types such as sounds, pictures (including animation), and composite 
objects would be a good start. However, relational databases will never be a 
complete solution as they lack the ability to store functionality associated with the 
objects that they store. 

Object-oriented databases need only add support in their class libraries for 
relations, records, and relational operations. The five basic relational operations 
should be supported in every OODBMS. This adds to the credibility of the system, 
and would help to standardize these types of databases. 
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B. WHY A RELATIONAL/OBJECT-ORIENTED DATABASE 



The main reason that a relational/object-oriented database is important is 
because the world consists of objects that can and should be represented in a state 
that more closely represents their true structure. An object-oriented database can 
represent objects; however, current object-oriented database systems lack the 
mathematical foundation relational databases provide. Relational databases lack the 
modeling power of object-oriented databases, however, they provide a rich set of 
operations and rules for manipulating data. A combination of the two is a logical 
step in the advancement of database technology. 

An example of how a relational/object-oriented database could be used was 
presented in [Nels88] and bears repeating. The example is a real estate database. It 
was pointed out that most real estate databases are already maintained by relational 
database systems. However, if a realtor wants to maintain all of the textual data 
regarding a piece of property, as well as blueprints and drawings of the house, most 
relational databases fall short. Also the database is not capable of storing maps of 
the surrounding neighborhood so that prospective clients can see what the general 
layout of the neighborhood is like, where the schools and churches are, and so on. 

In a relational/object-oriented system, each record for a piece of property could 
have a blueprint stored in it as well as coordinates of the property that could be cross 
referenced to an area map. Depending on the query, a textual listing of the property 
information could be generated, or a picture could be displayed, or a combination of 
the two could be displayed. Also if the realtor wants to give the prospective buyer a 
map showing the property and its surrounding neighborhood, a map could be printed 
by performing a query on the table holding the property listings as well as the objects 
containing maps of the city. 
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C. WHY THIS WAS THE APPROACH TAKEN 



This thesis extends the ROOMS concept into a full-fledged R/OODBMS. The 
R/OODBMS is implemented in Prograph, an OOPL that includes built-in database 
primitives for storing and retrieving objects in secondary storage. An R/OODBMS 
is also currently being implemented in a commercially available OODBMS 
[Spea92]. That implementation (when complete), along with this implementation, 
will complete the proof of concept of the feasibility/viability of an R/OODBMS 
which can meet the needs of both relational and object-oriented users. 

Prograph was chosen as the language for this implementation primarily because 
it does offer built-in database primitives, as well as other desirable features. This is 
favorable because all of the file creation and accessing is done through these 
primitives, allowing the design and implementation to focus on the relational/object- 
oriented database concept rather than being bogged down with the details of reading 
and writing information to the disk. Some features were exploited and are discussed 
in the following chapter, however, these features can easily be replaced if desired. 
Another reason for choosing Prograph is because it exists on the Apple Macintosh 
which has a standardized operating system and routines available in ROM to handle 
the manipulation of pictures and sounds much more easily than any other platform. 
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IV. AN R/OODBMS IMPLEMENTED IN PROGRAPH 



This chapter presents the design decisions and basic assumptions made in the 
development of this relational/object-oriented database system. The structure of the 
database is described and the Prograph classes designed for this thesis are explained 
in detail. Source code for all classes is contained in Appendix C. 

A. BASIC ASSUMPTIONS 

This database is built around six basic assumptions: 

1) . the database applications will be developed in Prograph 

2) . a persistent called current DB exists 1 

3) . the records stored in each relation must be instances of the same type 

4) . all records being stored in a relation must be descendents of class 

Record 

5) . every relation contains at least one key 

6) . every relational operation returns an instance of Temp Relation 

Many design decisions affecting this implementation rely heavily on these 
assumptions holding true. The following sections give more detailed descriptions of 
why these assumptions were made and how they affect the database design. 

1. Applications Will Be Developed In Prograph 

This assumption is made because the only way to design classes in 
Prograph is through the Prograph environment. Alternatively, it is possible to design 
a Record class that contains an attribute which is a list; this list could be then be 
treated as a “set” so that all the attributes of the record could be stored in a particular 
position in the list. This would allow users to build relations without going into the 
Prograph environment, as long as an appropriate interface is provided. However, it 



1. This persistent can easily be created when the R/OODBMS application is created. 
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would also reduce the types of objects that could be stored in a relation because users 
would be unable to develop their own classes to be stored as records. Using the list 
approach also reduces the objects being stored to values only. Therefore, a major 
benefit of storing objects is lost because the value-only objects lack function. 

Access to the Prograph environment is also required because some methods 
of Record and Relation should be over-shadowed for user-defined objects to be 
handled properly. The class Record, for example, makes some assumptions that are 
only true for simple objects. An example is the keys method of Record which 
defines every attribute of the user-defined record to be a key. This is a safe 
assumption if all the attributes are simple such as a strings or real numbers. 
However, if the attribute is not a simple type, it cannot be a key in a Prograph 
database. For example, an attribute that is an instance of another class could not be 
used as a key value because keys in Prograph are limited to boolean, integer, natural, 
real, and string. 

2. Current DB Persistent 

A persistent is assumed to exist called current DB. It is used to allow locals 
within methods to open the database tables without requiring the method to have an 
input of the current Database instance just to pass it to the local. Since access to the 
database file is achieved through the database id, and access to the Structure Table 
is through the Structure Table id, both pieces of data are required to open an existing 
relation. It was decided that the logical course of action is to use the persistent rather 
than clutter every method with extra terminals. 

This assumption is related to the database application and as such it is 
assumed that the database developer will provide this persistent, or selectively load 
it. The second reason for creating a current DB persistent is because Prograph allows 
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multiple database files to be open, and current DB provides a convenient place to 
store an instance of the database currently being manipulated. 

3. Relations Contain Records of the Same Class 

To model a relational database, all the records in a relation must be of the 
same class. The reason is because all records in a relation are made up of attributes, 
each with specific domains. Each tuple in the relation has corresponding attributes 
with the same domains. In general, it does not make sense to put different types of 
records in one relation; rather, they should be stored in different relations. For 
example, if the user decides to create two types of employee objects, say an 
hourly _employee and a salaried_employee , to be stored in a database, then there 
should be a class definition for each. If each type of employee is of a different class 
because they differ in some way, then they should not be stored together in the same 
relation. Even if they have exactly the same attribute types but function differently, 
they should be separated into two different relations. This is primarily a database 
application design issue, but this constraint is imposed to more closely adhere to the 
relational model. 

4. User-defined Records Must Be Descendents of Class Record 

This is a very important assumption, because when the end-user tries to 
create a new relation to be stored in the database the system looks for descendants 
of class Record and only allows the user to select one of these dependents to be 
stored in the relation. The system also names the relation based upon the name of 
the class being stored in the relation. In other words, if the user wishes to create a 
relation called Person, then there must be a class Person defined as a descendant of 
Record and there must not already be a relation called Person declared in the 
database. The assumption that relations are made up of records is used both directly 
and indirectly in many methods. 



52 



5. Every Relation Contains At Least One Key 

As previously discussed in Chapter II, the only way to access a cluster 
directly is by using the cluster id, and indirect access is achieved through keys 
associated with clusters. In order to access the clusters in the database, a key called 
-primary key has been defined for all relations. The ~ is used to ensure that it will 
be the last key associated with a table; also, if the user wishes to define a key called 
primary key there will not be a name conflict. The value of this key is determined 
by the application programmer. The intended use for this key is to store the primary 
key (in other words a unique value associated with the record) of each record since 
every record must be unique in a relation. However, this key is not limited by this 
convention. 

One use of the -primary key is to store a default value of ‘a’ or ‘1’ for 
every tuple. This has the effect of ordering the keys in the order in which the records 
are written to the database. 

6. Every Relational Operation Returns A Temp Relation 

Every relational operation has to return the same kind of result for 
consistency. It does not make sense to have one operation return a Relation while 
another returns a list, or a Temp Relation, or something else. This is important when 
considering the Cartesian product and projection operations. These two operations 
do not normally return relations that look like any other relation. 

The reason a Temp Relation is returned rather than a Relation is because 
tuples of a relation are actually stored as instances of the class that defines them, 
whereas the results of relational operations may not be instances of a specific class. 
Temp Relations are written to secondary storage as lists, because Prograph does not 
allow declaration of classes on the fly and because a Prograph list can have instances 
of classes or any other object as an element. For example, if the user performs a 
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Cartesian product operation on two relations, the result is a new relation with tuples 
containing all the attributes of the first relation and all the attributes of the second. 
There is no way to anticipate all the Cartesian product queries the user will perform, 
so there is no way to define a class for each Cartesian product result. Similarly, there 
is no way to anticipate all the projections a user will make, so classes cannot be 
defined for this operation either. 

B. DESIGN DECISIONS 

Before designing the classes for this implementation, some decisions as to the 
structure of the database had to be made. These included how to represent the 
relations and how to implement the relational operations. 

It was determined that a class called Relation should be created. Instances of 
this class require only three attributes. First is the relation name, which is taken 
directly from the class definition of the class to be stored in the relation. Next is 
attribute-names which is a list of all the attributes of the tuples in the relation. The 
last attribute is attr-types, which is also a list containing the type of each attribute. 

It was also decided that each relation should be stored as a Prograph database 
table containing instances of Records as clusters, and that each instance of a 
Relation would be stored in a Structure table. The Structure table contains a single 
entry for each relation stored in the current database. These entries are instances of 
Relation and have a key value associated with them for fast retrieval. The key value 
is the name of the relation so all relations must have different names. 

The decision was made to represent the relational operations as methods of the 
class Relation. In examples provided by TGS Systems with Prograph, they have 
implemented some of the relational operations as separate classes rather than 
methods of a class Relation. In examining relational databases and the relational 
model, it became apparent that the relational operations should be methods, rather 
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than separate classes. The relational operations are functions or operations that act 
upon instances of Relations, and as such should be methods of the Relation class 
rather than separate entities that act upon objects of type Relation. The latter 
approach is more of a structured programming approach rather than an object- 
oriented approach. 

C. THE STRUCTURE OF THE DATABASE 

The database files created by applications using these classes all contain a 
Structure Table. This Structure Table, as previously mentioned, holds instances of 
every relation created for the database. This table is required because once a relation 
is created, information about it needs to be stored for future sessions. In a Prograph 
database, this information about the relation must be explicitly written to the 
database disk file or it will be lost from one session to another. This is because there 
is not a single large repository for all the database applications to use as in most 
OODBMSs. Each Prograph database is made up of two files, the database file and a 
key file, which do not have access to information about any other databases. 
Although Prograph database files automatically maintain the names of all the tables 
associated with the database, other information about the attributes in each relation 
is not maintained. Thus, without the structure table the user would have to create a 
new instance of a relation and compute the associated attribute characteristics every 
time a database is opened. Using the structure table approach, the user simply 
retrieves the relation instance from the table when it is required. 

When a new relation is created, the relation bears the same name as the class 
whose instances will be stored as tuples in the relation. This class representing the 
tuples must be a descendant of the class Record for this schema to work. Once this 
is done a Prograph table named for this class can be created and tuples can be written 
to the disk. 
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Every Relation, Temp Relation, and tuple is written to the disk file rather than 
being stored in memory. This feature provides consistency and some level of 
security for the data being stored. Previous implementations of ROOMS did not 
have secondary storage features and therefore the data lacked any permanence. This 
implementation has features that allow the use and manipulation of the data that is 
stored to a disk file. 

D. REQUIRED CLASSES 

To implement a relational/object-oriented database in Prograph four classes 
were designed. First is the class Database. Instances of this class are created for 
every database that is opened by the user. This is necessary because Prograph allows 
multiple databases to be opened at the same time, as well as a single database being 
opened by more than one application. The Database instances maintain the path to 
the open data file, as well as the information about the database file (i.e., the file 
name and the volume id as well as the Structure Table id). 

The next class that was required is the Relation class. This class is the 
workhorse of this design, containing attributes describing the keys to access the 
tuples of the relation as well as the path to the database. Most importantly, it also 
contains all of the methods required to perform relational operations on the data in 
the database. A descendant class of Relation is Temp Relation. This class 
represents derived relations and modifies some of Relation’s methods to handle 
these temporary relations. 

The last class required by this design is the class Record. This class is the root 
of the sub-tree containing user-defined classes that will represent the tuples of a 
relation. Each of the afore- mentioned classes are now described in greater detail. 
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1. Database Class 

This class contains basic methods required to create and access a Prograph 
database. A database object contains the following instance attributes: file name, file 
volume id, database id, Structure Table id, and temp relation list. File name and file 
volume id exist primarily to handle the opening and closing of the physical disk file 
(necessary for multiple access to the file). The attribute database id is a pointer (or 
path reference id) to the database file. Structure Table id holds a pointer to the table 
in the database that contains all the relations associated with the database. Finally, 
temp relation list is a list of temporary relation names created by user queries. The 
temporary relations (which are simply Prograph tables) are cleaned up by the close- 
dh method. 

Some of the methods required for this class are new-db, open-db, close-db, 
new-relation, and display-yourself. There are several other support methods not 
critical to the design of the overall system. The first method, new-db, presents the 
user with a standard Macintosh file creation dialog box and then creates the database 
files (database and key file) using Prograph database primitives. It also creates an 
instance of Database and a table in the database file to maintain the structure of the 
database (the Structure Table). Once the Database instance has been created, it is 
stored in a persistent named current DB to eliminate the need to constantly pass 
database instances from one method to another. There is also some error checking 
included to ensure that no NULL files are created. 

The next method in this class is the open-db method, which is responsible 
for opening a database file. It has no inputs because it uses Prograph primitives to 
display a standard Macintosh file selection dialog box which allows the user to find 
and select the database file to open. It then prompts the user to select the mode in 
which to open the database (either share, query, or update mode). Once the files are 
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opened, an instance of Database is created and placed into the current DB 
persistent and the database id is passed as the output of the method. Again there is 
error detection and handling to prevent the user from opening a NULL file. If a 
NULL file is selected this method generates a failure control and passes it to the 
calling method to be handled. 

Next is the close-db method, which removes the selected Database 
instance from the current DB persistent, deletes any temporary relations, then 
closes the database file.This method also requires no input and produces no output 
as there is currently only support for one active database at a time. 

A delete-db method is also provided to remove a database from the disk. 
This method presents a standard file selection dialog box and once the selection has 
been made, the user is asked to verify the delete. If the user acknowledges the delete, 
then the database file and the key file are permanently deleted from the disk. 

2. Relation Class 

There are three instance attributes of this class; relation name, attribute- 
names, and attr-types. Relation name contains the name of the class stored in the 
relation. Attribute-names is a list of attribute names of the class being stored in the 
relation. The value of this attribute is taken directly from the user defined class, 
which makes the application programmer responsible for putting in the correct 
attribute names. Since each tuple is made up of one or more attributes, this list is 
used to determine “union compatibility” and to verify selected attribute names for 
projections and selections actually exist in the relation being queried. Attr-types 
serves the same type of purpose as attribute-names , except that the elements of its 
list are the attribute types (i.e., string, integer, etc.) of the entries in attribute-names. 

This class contains many methods, some of which are required by other 
methods and some which exist to reduce redundant code in other methods. The 
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major methods required are: select-relation, add-tuple, remove-tuple, display 
relation, union, projection, selection, difference, and Cartesian product. 

The method select-relation takes as an input a Database instance and 
presents the user with a dialog box asking which relation to open. Once the user 
makes a selection, the corresponding Relation instance is retrieved from the 
structure table and returned to the caller. The purpose of this method is to retrieve 
Relation instances from the database file for use in the application. 

The add-tuple method takes as input an instance of a Relation and the tuple 
(object) to be added. The tuple is checked to ensure it is of the correct type to be 
stored in the relation. Then all of the key values are extracted so the appropriate key- 
cluster associations can be made, including the -primary key value. It makes use 
of a method defined for all Records called get primary’ key to get the value of the 
primary key. 

The remove-tuple method takes as inputs the Relation instance and the 
tuple id, and has no outputs. It is assumed that the user will have already selected the 
tuple to be deleted prior to calling this method. 

Display-yourself is a method that displays the relation one record at a 
time. This is a method that can be overshadowed to suit the needs of the application. 
There is one input, the instance of the relation, and no output because the output is 
directed to the screen. 

The next five methods to be discussed are the relational operations. 
These methods are able to handle any type of object that can be defined in Prograph. 
The application programmer can, however, re-write methods for any of the basic 
five operations to take advantage of the keys declared for their objects. For example, 
the select operation may be too slow because it looks at each record and compares 
the attributes to see if they are equal. If the attributes in question were stored as keys, 
search times would most likely decrease. 
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The three inputs to every relational operations are: a Relation, another 
Relation (or Temp Relation) or a list, and the resulting relation’s name. Every 
relational operation also outputs a Temp Relation, which is stored as a table in the 
Prograph database file with the resulting relation’s name as the name of the table. 

The union method opens both input relations and then writes every 
tuple of the first relation to the Temp Relation created. It then reads each tuple from 
the second relation and searches the first relation to see if their is a match. If a match 
is found, then it is not included in the Temp Relation, otherwise, it is added to the 
Temp Relation. This is done to ensure the uniqueness of every tuple in the result 
relation. 

The second input to the projection method is a list of attributes. The 
attributes in this list are compared to attribute-names in the input Relation instance. 
If they are valid, the method proceeds to read every tuple in the relation, writing only 
the values of the attributes requested to the Temp Relation. 

The second input to the selection method is the selection criteria in the 
form of a list containing the attribute for the comparison, the operation (=, >, etc.) 
and the value. The method calls upon the user-defined methods for equality (equal? 
greater-than?, etc.) to determine which tuples should be put into the Temp Relation. 
Default equality methods are defined in the Record class, but they are fairly simple 
as it is impossible to anticipate every object defined for a record. 

The Cartesian product method reads in a tuple from the first relation, 
converts it to a list, and then converts every tuple in the second relation to a list and 
appends them to first list. In other words, if the first relation has two tuples a and b 
and the second relation has three tuples x, y, and z, then the result of the Cartesian 
product will be a relation with six tuples: (a, x), (a, y), (a, z), (b, x), (b, y), (b, z). This 
method uses the -primary key to step through each relation. This implementation 
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could be looked at as two nested “For-statements” in a structured programming 
language. 

The difference method opens both relations, examines each tuple in the 
first relation and compares it to every tuple in the second relation to see if they 
match. If they do match, the tuple is not included in the resulting Temp Relation, 
otherwise, it is included. The comparison in this method is based upon the user- 
defined (or default) equals? method in the user-defined record class. 

3. Temp Relation class 

This class defines no new attributes; however, all relational operations are 
redefined. The reason these methods are redefined is because the Relation versions 
of these methods make the assumption that the attribute names are the names of 
actual attributes of a class. In contrast, the attribute names associated with Temp 
Relation objects are merely ways to locate the attributes based upon their position 
in the list that they have been stored in. For example, if a Temp Relation is created 
and has an attribute-names value of (lname, age), then a tuple stored in the Temp 
Relation could be (Filippi, 27). To retrieve the age attribute of this particular tuple 
the position of the attribute named “age” would have to be determined from the 
attribute-names list. Since the value of the position of the “age” attribute is 2, a get- 
nth (with n=2) could be performed on the tuple in question and the value 27 would 
be returned. In the Relation version, to retrieve the attribute age from a person 
record a “get” method is performed on an instance of person class with the attribute 
name “age” injected into the operation. 

All the changes to the relational operations have to do with how attributes 
are retrieved and how they are accessed. The algorithms for performing the 
operations are the same, so they will not be discussed further. 
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4. Record class 

The Record class has three class attributes: attr-types, attr-names, and 
keys. These attributes can either be set directly by the programmer when the classes 
are defined (i.e., default values can be set), or they can be defined when they are 
accessed. The purpose of the first two attributes is to provide the Relation class 
attributes the values they need to keep track of the attributes of the tuples being 
stored. The keys attribute is used to create keys for the relations in addition to the 
-primary key. For example, the programmer may design records with an attribute 
X that is the primary key, but know that many queries will be performed based upon 
a non-unique attribute Y. Then the attribute Y can be declared as a key by placing 
the attribute name Y in the keys attribute. Then when a selection method is written 
to overshadow the selection method of Relation, the key Y can be used to retrieve 
values from the relation, rather than reading every tuple to determine whether the 
condition is met. This is useful if the database application programmer wants to 
create a descendant of Relation and overshadow some of the relational operation 
methods. The applications programmer can then write these methods in such a way 
as to take advantage of the key and speed up the query. 

The methods provided with the Record class are attr-types , attr-names, 
keys, equal?, display-yourself, and get primary > key. The first three methods are set 

methods . These methods can be overshadowed by the programmer if deemed 
necessary. The keys method treats every attribute as a key and sets the value of the 
keys attribute to a list containing the attribute name of all the attributes of the class. 
This is fine if all the attributes are simple, but if the attributes represent a list or an 
instance of another class, they will not make valid keys and the system will most 
likely crash. 

2. Set as in “set” or “get”, vice "set theory”. 
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The equal? method evaluates two records and determines equivalence. If 
the objects are composed of simple attributes, this implementation of equal? works 
fine because the objects entering the method are converted to lists, and the lists are 
compared with the “=” primitive. For more complex objects an equal? method 
should be defined by the application programmer. 

Display -your self is a method that simply invokes the display primitive. If 
the record contains special types of objects such as pictures or sounds, it may be 
more desirable to create a display-yourself method with the appropriate interface to 
best display the object. Even for simple objects, a display window could be designed 
to make the result more aesthetically pleasing. 

The get primary key method must be over-shadowed unless the first 
attribute defined for the user-defined class is to be the primary key value. This 
method is designed to get the value of the first attribute declared in the class and use 
it as the primary key. If the primary key value is to be something more than a single 
attribute, the method should be over-shadowed. An example is, a company database 
that contains a relation between employees and projects. The combination employee 
number and project number might be the only way to distinguish one tuple from 
another (i.e., the primary key). If this is the case the get primary key method could 
be written to get the values of employee number and project number, concatenate 
them together and return the catenated value as the output of the method. 
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V. SUMMARY, CONCLUSIONS, & SUGGESTIONS FOR FUTURE 

RESEARCH 



The purpose of this research was to design and implement a relational/object- 
oriented database system with secondary storage features. This was a continuation 
of a previous research project and has satisfactorily demonstrated that the concept 
of a relational/object-oriented database management system as proposed in [Nels88, 
NMO90] can be extended to a system with secondary storage. 

A. SUMMARY 

A detailed literature review was accomplished in which object-oriented 
programming, databases, and Prograph were investigated. The feasibility of creating 
a relational/object-oriented database system was determined, and an 
implementation was proposed and implemented. 

The implementation is language dependant, but shows that the concepts are 
valid for any OOPL with secondary storage features. Therefore, the concepts 
proposed are also valid for an OODBMS (which can be considered to be 
specializations of OOPLs). 

B. CONCLUSIONS 

OODBMSs can be used to store and manipulate relational databases. Since it 
was shown to work in a lisp-based language designed to be bolted on top of an 
OODBMS [Nels88, NMO90], and it has now been shown to work in an OOPL with 
secondary storage features, it is safe to say that it should work within any OODBMS. 
Since OODBMSs contain all the features of OOPLs, along with the ability to handle 
the storage and retrieval of data to and from secondary storage devices, they should 
therefore be able to handle both relational, and object-oriented data within the same 
system. 
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C. SUGGESTIONS FOR FUTURE RESEARCH 



Future research in this area should include, but is not limited to, the following 
areas: implementation of relational operations in a commercially available 
OODBMS, optimization of relational operations in an OODBMS, allowing 
complex objects to be keys, declaration of a standard class library for OODBMSs to 
include the relational operations, and extension of the ideas presented here to 
include addition of other types of databases to OODBMSs. 

1. Implement Relational Operations in a OODBMS 

Although this project implements a relational/object-oriented database, the 
final proof of concept is whether or not this idea can be implemented in an existing 
OODBMS. The class libraries available in OODBMSs are usually very rich and 
should provide a means for implementing the ideas posed herein in a much more 
elegant and efficient way. 

Once an OODBMS implementation is completed, the proof of concept for 
adding relational operations to an object-oriented database management system will 
be complete. 

2. Optimization of Relational Operations 

The relational operations presented in this thesis were written to prove that 
relational operations could be added to an object-oriented system with secondary 
storage features. Although this was demonstrated, the time required for some queries 
on large relations is unacceptably slow. This is because the relations are retrieved 
from secondary storage and then written back to secondary storage in a different 
form for every query. Disk access time, even on a fast system, makes these 
operations perform at a less than desirable speed. 
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3. Allow Complex Objects to be Keys 

In this implementation the values of keys are limited by the language to 
booleans, integers, real numbers, or strings. In a general purpose R/OODBMS it is 
important to allow arbitrarily complex objects to be key values in a relation. 
Limiting keys to simple data types limits the usefulness of the system in much the 
same way as the limited number of data types available in conventional relational 
database systems limit their use. 

4. Addition of Other Types Of Databases To OODBMSs 

Although relational databases can be represented in an OODBMS, what 
about hierarchical or network databases? Initial work has been done in this area 
[FN92b], but a more detailed design and implementation should be attempted to 
determine whether OODBMSs are able to efficiently handle the various data 
models. The implementation of a hierarchical database and a network database 
within an OODBMS should sufficiently prove the point that OODBMSs are indeed 
sufficient to allow the storage and retrieval of all types of database systems. 

5. Standardized Class Library For All OODBMSs 

Once a determination as to the feasibility of implementing all the current 
data models within the confines of OODBMSs is established, a logical step would 
be the standardization of the class libraries associated with each vendor’s 
OODBMS. Just as SQL is the standard for relational database languages, a standard 
minimum requirement should be developed for all OODBMS vendors. This would 
ensure that regardless of which OODBMS you had access to, you would still be able 
to use it to store and manipulate the type of data in any way desired. 
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APPENDIX A - CREATING A SAMPLE DATABASE APPLICATION 



A. BASIC ASSUMPTIONS 

It is assumed that the user has a working knowledge of Prograph and database 
design issues. The primary purpose of this appendix is to show how to utilize the 
tools provided in the classes written for this thesis. 

B. DESCRIPTION OF THE METHODS PROVIDED 

Appendix B presents all of the methods in each class in their graphical 
representation. The inputs and outputs for the methods that will be directly called by 
the user are annotated in the graphical representations. All of the methods that 
should be called by the user are briefly described in the following paragraphs. For a 
more detailed description of each method see Chapter IV and Appendix C. 

1. Database Class 

The following methods of the Database class should be used by the 
applications programmer to create a database application. 

a. new-db 

Used to create new database files (the database and the keys file). This 
method fails when the db-new primitive fails. 

b. open-db 

Used to open an existing database. This method fails if the db-open 
primitive fails. 



c. close-db 

Closes an open database. 
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d. delete-db 



Deletes an existing database from secondary storage. 

e. rename-db 

Rename a database. 

/. display-y ourself 

Uses the show primitive to display a list containing the names of all 
relations in the Database. 

g. new •relation 

Creates a new relation based upon the sub-classes of Record. This 
method fails if the database is not opened in update mode. 

h. delete-relation 

Provides the user with a dialog box from which a relation can be 
selected for deletion. 

2. Relation Class 

The following methods should be used by the applications programmer to 
create and manipulate relations in a database. 

a. select-relation 

Presents a dialog box containing every relation that exists in the current 
database, returning the relation selected. 

b. add-tuple 

Adds a tuple to a relation. The inputs are an instance of Relation and 
an instance of a user-defined record (tuple). 
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c. remove-tuple 

Deletes a tuple from the relation. It is assumed that the cluster id for the 
object has been retrieved so the cluster (tuple) can be deleted. 

d. union 

Performs a union of two relations. Every tuple from the first relation is 
written to the Temp Relation, and every tuple from the second is evaluated to see if 
it is the same as one from the first relation; if it is, it is not written to Temp Relation. 
This method fails if the two relations are not union compatible. 

e. selection 

Retrieves every tuple from the relation whose attribute(s) satisfy a 
selection condition and places the results in a Temp Relation. If the attribute(s) used 
in the selection condition does not exist in the relation, this method will fail. 

/. projection 

Retrieves only the requested attribute(s) from every tuple in the 
relation, placing them in a Temp Relation. 

g. Cartesian product 

Produces a Temp Relation that contains tuples created by appending 
the value of every tuple from relation number two to each tuple of relation number 
one. The Temp Relation has as many attributes as the sum of the two input relations 
and as many tuples as the cross product of the relations. 

h. difference 

Produces a Temp Relation with all of the attributes that are in the first 
relation not in the second relation. This method fails if the two relations are not 
union compatible. 
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i. display-yourself 

Uses the system defined primitive display yourself to display every 
tuple in the relation. 

3. Temp Relation Class 

The methods of this class have the same functionality as the Relation class 
methods of the same name. The only difference is that these methods have as the first 
input to each relational operation an instance of a Temp Relation, whereas the 
Relation counter-parts have a Relation as the first input to the relational operations. 

4. Record Class 

These methods will most likely be over-shadowed by descendents of 
Record. However, since these methods must be present in some form, they are 
included in the class definition of Record. 

a. =, n <; >, ^ ^ 

All of these methods take two tuples and compare them. The 
comparison operations provided here are based upon the tuples containing simple 
attributes, and the attributes values are compared to determine equality. 

b. display-yourself 

This method uses the system defined display primitive to display the 

record. 

c. get primary key 

This should definitely be over-shadowed unless the primary key 
happens to be the first attribute declared in the record class. 
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C. BUILDING A DATABASE APPLICATION 



1. A Simple Application 

The sections that follow will take you through creating a very basic 
database application which can be run in the Prograph Editor or compiled into a 
stand alone application. 

2. Basic Description of the Application 

We will be creating a simple database of people records. There will be two 
kinds of people, students and teachers. Each type of person has the attributes: last 
name, first name, age, sex, address, and widget. The first four attributes are simple 
attributes, the address attribute is another class containing the attributes number , 
street name, city, state, and zip code. The widget attribute is an arbitrarily complex 
object. 

Since we have two different types of people, we will create the class people 
with the descendants students and teachers. Since Prograph does not currently 
support multiple inheritance, people must be a descendant of Record, and students 
and teachers must be descendants of people. 

We will now show how to create a single database to hold the relations 
students and teachers, and how to perform relational operations on these relations. 

3. The First Step 

The first thing to do after opening Prograph is open the Classes window by 
selecting it from the Windows menu. Next, selectively load all the classes from the 
file Thesis.pgs. This is done by selecting Open from the File menu. When the open 
file dialog box appears click on the Selective Load check box (this will also 
automatically select the Incremental Load check box), navigate to the file Thesis.pgs 
and choose the Open. . . button. This presents a list of all the classes in the file. Select 
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every class by holding down the shift key and clicking on every class name (all of 
the current Prograph System Classes are included in this file). Now do the same 
thing with the Universal methods. Open the Universal window by selecting 
Universal Methods from the Windows menu and repeat the steps above for opening 
the Thesis.pgs file. Instead of a list of classes in the selection window, a list of all the 
methods in the file is presented. Select only the methods named make list, make 
class list, and read & write. The final thing to do is open the Persistents window by 
selecting it from the Windows menu and create a new persistent by clicking in the 
white space of the window. When the new persistent appears, name it current DB. It 
is very important that it be named correctly, note that Prograph is case sensitive, so 
it must be typed exactly as it appears. 

4. Create The Classes 

Open the Classes window (which looks like Figure A.2). Click anywhere to 
create the address class. Once a class icon appears in the window, type address and 
then double-click on the left side of the icon to open the attributes window for the 
class. This is where the attributes number, street name, city, state, and zip code are 
created and given default values. Click in the white space of the attributes window 
to create a new attribute. When the icon appears, type in the attribute name (i.e., 
number). Do this for every attribute. After creating all of the attributes, close the 
window so that the Classes window is in view. 

Repeat the above procedure for the people class. Except this time after 
creating and naming the address attribute, double click on it. A window opens that 
allows the value of the attribute to be set. Scroll up the list on the left to the word 
address. Select address by clicking on it and then press the OK button. The default 
value of the attribute address is now set to be an instance of the class address. 
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kext, create a sub-class of people. Begin by clicking on the people class 
icon. Then while holding down the option key, move the mouse to some white space 
and click the mouse button. A new class icon will appear with a line connecting it to 
the class people. Type the word students to name the new class, then repeat the 
procedure and create a new class called teachers. Once this is done the Classes 
window should look similar to Figure A. 2. Now that all atuibutes for students and 
teachers are finished, the only thing left to do is to attach the class people to the 
Record class icon. Do this by clicking on the Record class icon until it highlights, 
hold down the option key, and click on the people class 

The user interface can now be designed as in any Prograph application. The 
next few paragraphs present a very basic interface; for more detailed information 
refer to [TGS88a, TGS88b, TGS91]. 
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5. Creating the Interface 

Keep in mind that the windows to be used for data entry, the windows to be 
used to display the results of queries, and the query building window must be 
developed. Since this application has relatively few queries that will be performed, 
we will create a button for each specific query (e.g., a button for selection, a button 
for projection, etc.). Another possibility would be to provide an interface that allows 
the user to build queries dynamically. 
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a. Creating the Query Interface 

To create the query interface, select Edit Application from the Exec 
menu. This brings up a window that allows windows and menus for the application 
to be created. We will now create a window that contains five buttons representing 
the five basic relational operations. Select Window from the Classes scrolling list 
on the lower left-side of the window, and then click on the >New Instance> button 
below the list. This creates a new instance of window named Untitled. Double-click 
on Untitled to open it for editing. Once the window is created, click in the white 
space to create a new object. Once the object appears, double-click it to open a 
dialog box to set the type of the object. When the dialog box opens, Button is 
selected by default so all that is required is to click the OK button. Once this is done, 
another dialog box opens which allows the button to be named and a method 
associated with it to be called when the button is clicked. Name the button Selection. 
There is also a field for Click Method, type in “Selection”, and click the OK button. 
This button, when clicked, executes a universal method called Selection. Create the 
other four methods just like the Selection button. Once they are completed, hold 
down the option and command key and double click on the white space in the 
window. This brings up a dialog box that allows the window to be named and other 
parameters to be set. Type in “Queries” in the Window Title field then click OK. 
The interface for the queries window is now complete. 

b. Creating the Data Entry Interface 

To create an interface to allow the user to enter data into the database, 
create a new window as previously described. Rather than Buttons, create Edit Text 
objects on the window, one for each attribute of people objects (including the five 
for address) except for the complex object widget, and name the objects the same 
names as the attributes they represent. These Edit Text objects will be used by the 
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end-user to type in the values to be stored in the relation. Depending upon what type 
of object a widget is, an interface specifically designed for the widgets would have 
to be created. Also create a button named Student and another named Teacher. 
Once this has been completed, name the window (just like the previous window) 
“Data Entry” and then close the window. 

Now select each window from the scrolling list on the Application 
window and press the Add To Active List button. This adds the new windows to the 
application, and these windows will be opened upon start-up of the application. 

c. Creating the Menus 

Finally, a menu should be added to the application that allows the end- 
user to open and close databases as well as select relations to open. To create a menu, 
select Edit Application from the Exec menu. When the window opens select the 
Menus radio button and create a new instance (just like when the window instances 
were created) and open it for editing. Name the menu “Database”, and tab to the 
Item field. Type “New DB” in the Item field. Tab to the Method field and type “New 
DB”, then click the Insert After button. Repeat these steps for “Open DB” and 
“Close DB”. Click the OK button when finished. Now create a menu called 
“Relations”, and create menu choices for “Open Relation” and “New Relation”. 

Now return to the Application dialog, select the menus just created, and 
click the Add To Active List button. This adds the new menus to the applications 
menu bar when it is run. 

D. COMPLETING THE DESIGN 

Now that the interface has been built, run the application and build the methods 
for each button and menu item created while the program is executing. To do this, 
select Run from the Exec menu. Both windows should appear, unless they were 
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designed on top of each other. If this is the case, select the title bar of the foreground 
window and move it to expose the other window. 

Once both windows are visible, select New DB from the Database menu. A 
dialog box is presented stating that the universal method “New DB” does not exist, 
do you want to create it? Respond by clicking the OK button. This will open a 
method window with a dotted background. Double-click in the window to open its 
editable case window. Now create an operation to call the new-db method in the 
Database class. This method does not require any input terminals, and when 
Prograph menu items call a method they always send it the instance of Menu, the 
Menu Item, and an Event Record. Close the case window and press return to 
activate the operation that was just created in the method window. When this 
operation executes it will present the dialog box previously describe for the new-db 
method. Now do the same thing with the Open DB and Close DB menu items. 

Repeat the above procedures for the Relations menu except that when adding 
the operation to each case window, it will be necessary to create an additional 
persistent operation to get the value of current DB to feed into the Relation/select- 
relation method (to open a relation) and Database/new-relation (to create a new 
relation). 

Now that the menus are done, the same type of thing must be done for the 
buttons in the windows. The Queries window buttons will all require the user to 
specify which relation/relations will be operated on, and what the resulting Temp 
Relation will be called. The values can be obtained by using select-relation to get 
the relation instances, and the ask primitive can be used to get the result name as 
well as the list of attributes or selection condition depending on the relational 
operation being performed. The root of the relational operations can be attached to 
the Temp Relation/display-yourself operation (which will display every tuple in the 
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Temp Relation). In a more sophisticated implementation a window with scrolling 
fields or other features would be used 

The Data Entry window has only the two buttons Student and Teacher, and 
the methods for these buttons can be created the same way as the previously 
discussed buttons and menu items. For this implementation the buttons will both 
make use of the Relation/add-tuple method to add the tuples to the database. They 
will differ in that each will create an instance of the appropriate class (either 
students or teachers) and this instance will be written to the correct relation by the 
add-tuple method. 

Once all the buttons and menu items have been created and fully implemented 
a very simplistic application has been constructed. It could be compiled into a stand- 
alone application by the Prograph Compiler or it can be used in the interpreted 
mode. Naturally, some of the other features provided have not been discussed, but 
could be easily implemented. 

E. DETERMINING WHICH METHODS TO OVER-SHADOW 

1. Database Class 

The only method that might require over-shadowing is the display-yourself 
method. This method displays a list containing every relation defined for the 
database. It uses the show primitive to display the list of relation. 

2. Relation Class 

The display-yourself method could be over-shadowed by the programmer 
because the current implementation reads every record in the relation and displays 
them with the display primitive. Some of the relational operations could also be 
over-shadowed (as mentioned in Chapter V) to take advantage of keys associated 
with the user-defined records. 
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3. Temp Relation Class 

None of the Temp Relation methods should be over-shadowed. 

4. Record Class 

Virtually all of the methods associated with Record can be over-shadowed. 
The purpose of this class is to act as a guide for developing new records, but the 
methods make no assumptions about the structure of user defined record. The only 
assumptions made in these methods are that the class attributes contain the 
appropriate values. What values go into these attributes are completely up to the 
designer. 

The equality operations (=, *, <, >, <, and >) should be over-shadowed to 
correctly handle comparisons of the objects. If these are not over-shadowed, some 
relational operations may not return the expected results. 

Display-yourself should be overshadowed to properly display the objects. 
If it is not over-shadowed, the display primitive is used. This method should be 
over-shadowed as part of the user interface design so when the records are 
displayed, your windows are used. 
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APPENDIX B - ATTRIBUTES AND METHODS 



V Database 



v 

file name 

0 

V 

file volume id 
0 

v 

database id 
0 

v 

Structure Table id 




temp relation list 



©Database 



3 

ne w-d b 



Input: None 
Output: DBId 



3 

delete-db 



Input: None 
Output: None 



_s_ 

open-db 

3 



Input: None 
Output: DBId 



s 



Input: None 
Output: None 



rename-db 



Input: None 
Output: None 



close-db 



Input: None 
Output: None 
Uses the show primitive 
to display a list containing 
d i s p I ay-y o u rse I Ithe names of all relations 
in the Database 



S 



5 Input: «Database» 
Output: «Relation» 

new-relation 

Input: None 
Output: None 

delete-relation 





temp relation list 
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VRelation 



v 

relation name 

NULL 

V 

attribute-names 




attr-ty pes 



©Relation 



_s 

open 



Input: «Relation» 
Output: Tableld 

table 




Input: «Relation» 

Output: Primary key Id, Table Id 



open to first tuple 



S 

union 



Input: «Relation>>, «Relation», result_name 
Output: «Temp Relation» 




Input: «Relation»,list of the form 
( attribute, operator, value), result_name 
Output: «Temp Relation» 



selection 




Input: DBId 
Output: Tableld 



select-relation 



S 



Input: «Relation>>, list of attributes, result_narr 
Output: «Temp Relation» 



7 

projection 




Input: <<Relation» 
Output: None 



display-yourself 



d 




Input: «Relation», «Relation», result_name 
Output: «Temp Relation» 



7 

ifference 




Input: name, «Relation» 
Output: «Temp Relation» 



7 

make Temp Relation 




lnput:«Relation», <<Relation», 
Output: «Temp Relation» 



Cartesian product 



result_name 



S 



Input: Table Id, tuple 
Output: None 



add-tuple 



verify 




Input: <<Relation>>, «Relation» 
Output: <<Relation>>, <<Relation>> 



union compatibility 



re 



S 



7 

move-tu 



Input: «Relation», Cluster ID 
Output: None 

pie remove 



S 

7 

duplicates and write R2 
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VTemp Relation 



NULL 

V 

relation name 
NULL 

V 

attribute-names 

NULL 

V 

attr-ty pes 



®Temp Relation 



s 

\y 

union 

in 



Input: «Temp Relation», «Temp Relation», result_name 
Output:«Temp Relation» 

Input: «Relation»,list of the form 
( attribute, operator, value), result_name 
Output: «Temp Relation» 



selection 




Input: «Temp Relation», list of attributes, result_name 
Output: «Temp Relation» 



projection 




Input: «Temp Relation», «Temp Relation», result_name 
Output: «Temp Relation» 



v 

dif f ere nee 




Input: «Temp Relation», «Temp Relation», 
Output: «Temp Relation» 



Cartesian product 



result name 



_SJ 

decompose 



Input: an empty list, the list to be decomposed 
Output: decomposed list 

lists 




Input: an empty list, the list to be decomposed 
Output: decomposed list 



open Temp Relation 
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V Record 



8 

a 1 1 r-t y p e s 

attr-names 

6 



(JpRecord 



Inputs: «Record» 

Output: «Record» with value of attr-types 
set to a list of attribute values 

attr-types 





Input: <<Record» 

Output: none 

Uses display primitive to show an instance 
of a Record. This method should be 
overshadowed by the user of these classes 




keys 



display-you 

Input: «Record» 

Output: <<Record>> with keys set equal to 
a list of all attribute names. 

All attributes will be treated as key 
values unless this method is over-shadowed 




Input: «Record» 

Output: «Record>> with attr-names set to 
a list of attribute names 



attr-names 



get 



3 

r 

primary 



rself 



Input: «Record» 

Output: primary key value 

This method selects the first attribute created 

for objects of this class and returns its value 

as the primary key. This Method should be 

OVER-SHADOWED by the user 

key 




Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares ail attributes of two tuples 
and determines equality. 





< 



Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares all attributes of two tuples 
and determines inequality. 

Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines <. 




Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines >. 




Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines 




> 



Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines >. 
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APPENDIX C - SOURCE CODE 



^Classes 




Application Menu Menu Item Window Window Item 




Database 



Relation 






w 

Temp Relation 




Record 
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V Database 



• * 

v 

file name 

0 

v 

file volume id 

0 

V 

database Id 
0 

v 

Structure Table Id 




temp relation list 



(jfpDat abase 



s 



Input: None 
Output: DBId 



new-db 



s 



open-db 



1 



S 



Input: None 
Output: None 



delete-db 



Input: None 
Output: DBId 



1 



Input: None 
Output: None 



rename-db 



Input: None 
Output: None 



close-db 



Input: None 
Output: None 
Uses the show primitive 
to display a list containing 
dlsplay-yourseilthe names of all relations 
in the Database 



I 



Input: «Database» 
Output: «Reiation» 

ne w-relation 





Input: None 
Output: None 



delete-relation 




temp relation list 
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E^Database/neiu-db 1:2 



l VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZD 
§1 .dbf 




§1. New Database Name: 



^Database/neui-db 2:2 

VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 

§1 



o 




tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz^ 

§1. No file was created, would you like to try again ? 
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E£3Database/neuj-db 1:2create table t> key 1:1 




1. Structure Table 

2. (string sensitive unique) 

3. Relation Table 



^Database/neiu-db 1:2make instance 1:1 



vzzzzzszzzzzz^zzzzzz^zzzzzzz zzz^ 



M ! 


S 




^ file namej 


\ , 


t 


<^file volume ld^ 





X 



^Structure Table Id ^ 



GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZh 
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^Database/open-db 1:3 



e 7ZZZZZZZZZZ2ZZZZZZZZZZZZZZZZZZZZZ) 




g^Database/open-db 2:3 



V ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 

§1 



o 




§1. No database was selected, would you like to try again ? 



^Database/open-db 3:3 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 
NULL 
l DBId 

GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ2^ 
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^Database/open-db 1:3select a mode 1:1 



V2ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 



§1 

Q 



share 



update 
0 






query 
n 



^answer^ 
o 



GZZZZZZZZZ&ZZZZZZZZZZZZZZZ2Z& 



. What mode do you want to open the database in? 



^Database/open-db 1:3make DB instance 1:1 




I. Structure Table 
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g£3Database/close-db 1:1 



v zzzzzzzzzzzzzzzzzzzzzzzzzzssz^ 



^current DB^ 



"5 database 



^ temp 'relation 'jl'si^ 

A __Si — 



^d’b-c 1 0 3^ 3333333 ^ current 



{ZZZZ2ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



^Database/close-db 1:1open file 1:1 
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^3Dalabase/delete-db 1:2 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 




. 'Are you sure you want to delete the database files associated with the database: * 



^Database/delete-db 2:2 

vzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz^ 

§1 




tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZh 
. No database was selected, would you like to try again ? 
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^Database/rename-db 1:2 



vzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz* 




GZZZZZZ2ZZZZZZZZZZZZZZZZZZZZZZZZZ& 



§1. Which database do you want to rename ? 
§2. What is the new name for the database ? 



^Database/rename-db 2:2 

VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 

§1 




^ / / r e nam e - d 



GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 

§1. No datbase was selected, would you like to Iry again ? 
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^Database/display-yourself 1:1 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ3 




GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ2. \ 



1. Relation Table 



^Database/display-yourself 1:1make list 1:1 






JZ 



n 


a — 






0 


>< 





^k«y-valu^„ 



^ a 1 1 a c h - 

== 0 

v;;uv;7;;uw;yAV?777Z'SA77777* 
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^Database/new-relation 1:2 




^Database/nem-relation 2:2 



VZZZZZZZZZZZZZZZZZZZZZZ22ZZZZZZZZZ } 

§1 




GZZZZZZZZZZZZZZ&ZZZZZZZZZZZZZ* 



§1. No Relation selected, would you like to try again? 
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^Oatabase/neui-relation 1 :2ge t class name 1:1 



List of tables 

that already (Record) O 

exist in DB Y 

.kZmake class lls£ 



t/. ' . i lA removes Record 
^detach-K . ..... 

*= ^ from the list 




gguTj 



Selected Class name 



tZZZZZ2Z2ZZZZZZS2ZZZZZZSZZZZ2ZZh 



NULL 0 



1. Please select the class being stored in this relation. 



^Oatabase/neui-relation 1:2make Relation inst. 1:1 
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^Database/new-relation 1:2add Relation to DB 1:2 




E^Database/new-relation 1:2add Relation to DB 2:2 






§1 




msmmamsBsssEsas mQ 



§1. The database is not opened in the correct mode. Must be in update mode for this to succeed. 
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^3Database/neiu-relation 1:2store relation in ST 1:2 




. Structure Table 



E^Database/netu-relation 1:2store relation in ST 2:2 

vzzzzzzzzzzzzzzzgzzzzzzzzzz^ 

§1 

l 

i.h.wa 

. You must be in update mode to perform this operation. 



^Database/neiu-relation 1:2get class name 1:1make eligible list 1:2 

== 

\ iOn)l 

yT 

\ ° i^j 

GZZZZZZZZZZZZZZZZZZZtZZZZZZZ^ 
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^Database/neiu-relation 1:2get class name lilmake eligible list 2:2 




v w 
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^Database/delete-relation 1:2 






VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ3 




GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



. 'Select the table to be deleted. 



^Database/delete-relation 2:2 






§1 




tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZh 



. No table was selected, would you like to try again ? 
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^Database/delete-relation 1:2uerify delete 1:2 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 




_a 
answe 



Yes (x] 

GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ 





§1. * and all the keys and data associated with it ?’ 

§2. ’Are You sure you want to delete the table named ’ 



^Database/delete-relation 1:2uerify delete 2:2 



vzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzza 



§2 

Q_ 



r p... o . 

'join 



I 



h 



§1 

_o 



tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZQ 



§1. Will not be deleted! 
§2. 'The Relation ’ 



^Database/delete-relation 1:2do deletion 1:1 
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^Database /delete-relation 1:2do deletion 1:1remoue from ST 1:1 




. Relation name 
!. Structure Table 
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^Database/temp relation list 1:1 



^ZZZZZ2ZZZSZZ2ZZZ2ZZZ2ZZ2ZSZZZZZZZ} 



^ j em p re fat) on 1 Isffl 

^ Vu a c h ”r ^ 

7 ~ 

^ t a m r e I a 1 1 o n 1 1 
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V Record 



8 

attr-types 

8 

attr-names 

8 



©Record 




Inputs: «R©cord» 

Output: «Record» with value of attr-types 
set to a list of attribute values 



1 1 1 r-t y p e 8 




Input: «Record» 

Output: none 

Uses display primitive to show an instance 
of a Record. This method should be 
overshadowed by the user of these classes 



dlsplay-yourself 




keys 



Input: <<Record» 

Output: <<Record>> with keyys set equal to 
a list of all attribute names. 

All attributes will be treated as key 
values unless this method is over-shadowed 




Input: <<Record>> 

Output: «Record» with attr-names set to 
a list of attribute names 



ttr-na tries 



get 




primary 



Input: «Record» 

Output: primary key value 

This method selects the first attribute created 

for objects of this class and returns its value 

as the primary key. This Method should be 

OVER-SHADOWED by the user 

key 



Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares all attributes of two tuples 
and determines equality. 



Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares all attributes of two tuples 
and determines inequality. 

* 

Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines <. 

< 







Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines >. 




Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines <. 




£ 



Input: 2 tuples 

Output: None. Suceeds or Fails 
Compares first attributes of each 
tuple and determines >. 
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^Record/attr-types 1:1 




<23Record/attr-types 1 : 1 get types 1:1 
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ORecord/attr-names 1:1 



^Z2ZZZZZZ^2ZZZZZZZZZZZ^ZZZZZZ3 




^attribute 






names? 

V 

TZZZZZZZZZl 



GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



^Record/keys 1:2 




ORecord/keys 2:2 



vzzzzzzzzzzzzzzzzzzzzzzzgzzzz& 



<<£Tb 1 I r - n a m e 
^ ““» • ^ 






tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz* 
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^Record/display-yourself 1:1 



1 7S2ZZ2ZZZ^ZZSZZ2ZZZ2ZZZZ2ZZZZ2^ 
^dlsplay^ 



GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ* 



^Record/get primary key 1:1 
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^Record/= 1:2 



vzzzzzzzzqzzzzzzzzzzzzz^zzzzzza 

( ) tuple 1 ( ) tuple 2 

-o A n >, 




{ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ2m 



gs3Record/= 2:2 



V ZZZZZZZZZ^ZZZZZZ2Z2ZZZ2ZZ^22ZZZZZ} 
tuple 1 tuple 2 

tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZQ 
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^Record/* 1:2 



( TSZZZZZZZ^ZZZZZZZZZZZZZ^ZZZZZ^ 
tuple 1 .tuple 2 

I 



GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ* 



^Record/* 2:2 



vzzzzzzzzzgzzzzzzzzzzzzzzzgzzzzzza 

tuple 1 tuple 2 

tZZZZZZZZZZZZZZZZZZ2ZZlZZZSZSZZSZ(^ 
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^Record/< 1:2 
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^Record/> 1:2 



vzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzza 




GZZZ2ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



^Record/> 2:2 



vzzzzzzzzzgzzzzzzzzzzzzzzgzzzzzza 

tuple 1 tuple 2 

f777777777777777777777777277V777ZZ7Q^ 
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^Record/s 1:2 




^Record/i 2:2 

VZZZZZZZZZgZZZZZZZZZSZZZZgZZZZZZZ} 
tuple 1 tuple 2 

GZ2ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZQ 
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^Record h 1:2 



VZZZZZZZZZZZZZZZZZZZZ&ZZZZZZZZ2 




ezzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz* 



^Record h 2:2 

VZZZZZZZZZgZZZZZZZZZZZZZZgZZZZZZD 
tuple 1 tuple 2 

<Z 7ZZZZZZZZZZZZ2ZZZZZZZZZZZZZ2Z22Z^ 
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V Relation 



• « 

v 

relation name 
NULL 

V 

a tt r I b ut e- n a m e 8 




attr-ty pes 



(jgjlRelation 




Input: <<Relation» 
Output: Tableld 



open table 



Input: «Relation» 

Output: Primary key Id, Table Id 

open to first tuple 




Input: «Relation>>, «Relation», result_name 
Output:«Temp Relation>> 

union 

Input: «Relation»,list of the form 
( attribute, operator, value), result_name 
Output: «Temp Relation» 

selection 






Input: DBId 
Output: Tableld 



select-relation 



Input: <<Relation>>, list of attributes, result_name 
Output: «Temp Relation» 

projection 





Input: «Relation» 
Output: None 



display-yourseif 



Input: «Relation», «Relation», result_name 
Output: «Temp Relation» 



difference 




Input: name, «Relation» 
Output: «Temp Relation» 

make Temp Relation 





lnput:«Relation>>, «Relation», 
Output: «Temp Relation>> 



Cartesian product 



result_name 




Input: Table Id, tuple 
Output: None 



add-tuple 



verify 




Input: «Relation>>, «Relation>> 
Output: «Relation>>, «Relation>> 



union compatibility 




Input: «Relation>>, Cluster ID 
Output: None 



remove-tuple 



remove 




duplicates 



and 



write 



R2 
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E^Relation/open table 1:1 



TZZZZZZZZZZZZZZZZZZ^ZZZZZZZZZZZZZD 

«Relalion» 

^ reia 1 1 o n n a m 


o 

PBy 

^database icf^ 

" 6 


i 


^table-open^ 


nj 

o © 

{ZZZZZZZ2ZZZZZZZZZZ2ZZ& 


r 

V/////////A 
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g^Relation/open to first tuple 1:1 



V ZZZZZZZZZZZZZZZZZZZZZZZZZgZZZZZZZZ) 



^current 


DE& 


i 


3 

i 


/ database 

‘a 


A 



% relation nam^ 




€ZZZZZZZ2ZZZZZZmZZZZZZZZZZ2Z& 
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^Relation/select-relation 1:2 



vzzzzzzzzzzzzzzzgzzzzzzzzzzzzzzzzza 




t/;;;;;Av;;;/////^////////////////* 



§1. Select the Relation you wish to open. 



^Relation/select-relation 2:2 



/s/sss s/ss/s ssss/s ////// 

§1 ’ 
o 


DBId 




No Yes 




„ 7/ A 

yy// a r 








~r^ 


DBId 



Yes R a a ^ / / o p e n - 1 a b I 



fZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ* 



§1. No table was selected, would you like to try again ? 
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E^nelation/display -yourself 1:1 



VZZZZZZZZZZZZZZZZZ^ZZZZZZZZZZZZZ) 



«Relation» 




GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



^Relation/display-yourself 1 : 1 do all records 1:1 
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^Relatlon/make Temp Relation 1:1 
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^Relation/add-tuple 1:1 




g^Relation/add-tuple 1:1make key ualue list 1:2 



vzzzzzzzzzzz&zzzzzzg. 




7Z2Z2ZZZZZ3 



key list 



r 



() 

Check to see if 
there are any keys 
associated with this 
table. If not return NULL 



[^attach-i^ 

0 



G22ZZZSZZZZZZZZZ^ZZZZZZZZZZZZZ2^ 



^Relation/add-tuple 1:1make key ualue list 2:2 

vzzzzgzzzzzzgzzzzzzgzzzzzzg zza 

key list 



NULL 



tZZZZ22ZZ^2Z2ZZZZZZ2ZZZZ2ZZZZ22^ 



119 



g^Rela t ion /remoue- tuple 1:1 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 

^^vDolo1i/%nvv Y tunic 



^current "dB^ 

^ d at u b a s e I 



*«Relation» 

% re I at (on na m <3^ 










tuple (Cluster ID) 



^ t a b I e^c I o s ^ c c cc ^ c » u » * * 1 j*H 



(ZZZZZZZZZZZZZZZZtZZZZZZZZZZZZZ^ 
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n 



g^Relation/union 1:2 



«Relation 1» «Reiation 2» result name 




^Relation/union 2:2 



^zzzzz^zzzzzzzzz^zzzzzzzzz^zzzzz^ 

«Relation 1» «Relation 2» 




NULL 



i 



«Temp Relation» 

GZZZZZZZ2ZZZZZZ2ZZZZZZZZZZZZZZZZ& 



The two relations are not union compatible 
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g^Relation/union 1:2make Temp Relation 1:1 



^cuVrent 

“T User selected Relation 1 

^ ^/Relation name 

tern p relation II 



^ Te mp ^Rela't'lT^ 



^ r el at Ion n a m 




^attr- types^ % at j rlbute - n a mt| 

a t t r Vb u t e - n a m e ^ 



{ZZZZZ2ZZZZZZZZZZZZZZZZZZZZZ2ZZZZ& 



^Relation/union 1:2openTemp Relation 1:1 




[^create temp relation table : 



3333 ^/open tabled 




-pri m ary key 



ey-o pe 

■0 xs 



tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz^ 
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^Relation/union 1:2uirite R1 lo Temp R 1:1 



VZZZZ2ZSZZZ2ZZZZZZZZZZ2ZZZZZZ2ZZ3 



A, 



^//open to f Irs tupl%] 



Temp 
Relation 




List of every 
instance in R 



f&ZZZZZZZZZZZSZZZ2ZZ2Z2ZZ2ZZZZZ2l 



£3Relation/union 1:2make R2 list 1:1 
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ORelation/union 1:2open Temp Relation 1:1create temp relation table 1:1 




^Relation/union 1:2write R1 to Temp R 1:1 read & write 1:1 
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ORelation/union 1:2make R2 list 1:1make list 1:2 




^Relation/union 1:2make R2 list 1:1make list 2:2 




^Relation/union 1:2make R2 list 1:1make list 1:2do all instances 1:1 
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ESRelation/union l:2make R2 list 1:1make list 2:2do all lists 1:1 




^^^^^ZZ22Z^ZZZZ22ZZZZZZZZZZZZZ^^ZZ^ 
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g£3Relation/selection 1:1 




^ at t rib ute name^ k , , \v, , , 

p t tr ~ ^detach-0 iKrJghgJfJ^g^lS^ 

<Relalion> \ ^n - g ^-r ro 4 J> 



„ ^ 

tx£^?P?rc .A?.. Jifgt tupi% 



f ? open T emp Relation ] 




;get the tuples- 

ifnpnjnb® 



r/////s///////////////j/s//////3//sz 



E^Relation/selection Irlmake Temp Relation 1:1 
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^Relation/ selection 1:1openTemp Relation 1:1 



«Temp Relation» 



«Tei 
^ re I at Ion n a me^ 




\ create temp relation table \ 333 ^//open_ 'ta’bif^j 




fk 






-primary key 



ey-ope 
~o cr 



G2ZZZZZZ22ZZZ2ZZZZZZZZ2ZZZZZZZZZ^ 



^Relation/selection 1:1 f i» operation 1:1 



l TZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZa 

/ 

r 

GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 
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E^Relation/selection f : 1 get the tuples 1:2 

t 




^Relation/selection 1 : 1 get the tuples 2:2 



7ZZZZZZZZZZZZZZZZZZ2Z^ZZZZZZZ3 

tzzzzbzzzzzzzzzzzzzEzzzzzzzzzzh 



E^Relation/selection 1:1open Temp Relation 1:1create temp relation table 1:1 
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G^Relation/projection 1:1 



^zz zzzszzzzzzzz^zzzzzzzzzzzz^zzzzzzzzzzzzzzsz^ 

«Relation» attribute^ list ,result_name 

^ // o p e n ( t a b I w** 



?33 j ^make temp relation J 



-primary key 
IS 



Temp Relation inst. 



k£key-opei 
— 0 



Itopen Temp Relation^ 



Table Id 



^ k'e y • fj r'g'^ >33»^f ocess \ n tup |o S : 

0 



Temp Relation instance 



ORelation/projection 1:1make temp relation 1:2 
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g^Relation/projection 1:1make temp relation 2:2 

^zzzzz^zzzzzzzzz^zzzzzzzzz^zz^ 

Relation attribute list 
§1 

tZ2ZZZZZZZZZZZZZZ&ZZZZZZZZZZZZZZ2^ 

I. On© of the attributes selected does not exist in the selected Relation 



^Relation/projection 1:fopen Temp Relation 1:1 



*2ZZZZ2ZZZZZZZZZZZZZZZZZZZ2ZZ^ 

ccTemp Relation» 



7ZZZ5Z7777Z 
yf «Ter 

^ r el ia t j o n ' n a me^ 




^create temp relation table j 333 ^//ope n ’ t ab j e^j 







-primary key 



^key-open^ 

— ry 73 — 

r/////////////////////////////7////^ 



^Relation/projection 1:1process all tuples 1:1 



k e y - r e a 
-O Q . 



V2ZZ2ZZZZZ^ZZZ^^ZZZ2ZZZ^ZZZZZ} 







—Q 



attribute list' 



3 D 3 



Table id 



^ write values to Temp Relation^ 



tzzzzzzhzzzbzzzzzzzzszzzzzzzz^ 
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^Relation /pro iection l:1make temp relation 1:2check attributes 1:2 




^ a ttac h -r^ 



ot) 



tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzm 



^Relation/projection 1:1make temp relation 1:2check attributes 2:2 




§2. The attribute: 



g^Relation/projection 1:1make temp relation 1:2make types list 1:1 
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ORelation/projection 1:1open Temp Relation 1:1create temp relation table 1:1 




^Relation/projection 1:1process all tuples 1 : 1 mri te ualues to Temp Relation 1:1 







fc%3 Relation/projection 1:1process all tuples 1 : 1 write values to Temp Relation 1 : 1 get all attributes 1:1 



' ZSZZZZSZgZZZZZ^ZZZZZZZZZZZZZZ) 

attribute list 



r—, S .y 

£a 1 1 a c h - 
VZZZZZZZZZZ2ZZ. 



GZZZZZZZZZ2ZZZBZ2ZZZZZZZZZZZZZZZZ& 
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^Relation/difference 1:1 



^ ZZ22Z2ZZZZZZZZZSZZZZZZZZZ22ZZZZ^^^^^^^^^^^^^^^^^^ 



^ //verify^ union’ c°rnpatibiiij^ 0>333 ^7/make Temp Rejatlo^ 

<Relation>\ > ^ <Relation> 

r// 

\y A //o p e n t . o f I r s t_ t uj? I i 




it r~rsrw 



tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz* 



^Relation/difference 1 : 1 R2 to list 1:2 
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E^Relation/difference 1:1R2 to list 2:2 




^Relation/difference 1:1 build Temp R 1:2 







^ 3 w » ;)j5 ” 5 



^k»y-nexl^ 







^compare to all o f R2 ; [X 



if there is a tuple in 
R2 that equals the current 
tuple, this methd fails 



£c I u s t e r - w V 1 t £ 



GZZZZZ2ZZZZZZ&ZZZZZZZZ2ZZ^2Z^ 



^Relation/difference 1 : 1 build Temp R 2:2 



Gzzzzzzzzzz2zz&zzzzzzzzfrzzzz& 
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E^Relation/difference 1 : 1 R2 to list 1:2do instances 1:1 







^£kay-read^ 


& — — ° P 


0 X 333«33335: 


^key-nax^ 


1/ 

^aft'ach.^ 

V 





{ZZZZZtt&ZZZZZZ2Z22ZkZZZZZZ& 



^Relation /difference 1:1R2 to list 2:2do list types 1:1 




^Relation/difference 1 : 1 build Temp R 1:2compare to all of R2 1:2 
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^Relation/difference 1 : 1 build Temp R 1:2compare to all of R2 2:2 



I -zzzzzzzzzzgzzzzzzzzzzzzzzgzzzzzza 
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^Relation/Cartesian product 1:1 




E^Relation/Cartesian product 1:1make Temp relation 1:1 




§1. relation name 



^Relation/Cartesian product 1:1process tuples 1:1 




E^Relation/Cartesian product 1:1process tuples 1:1process Relation 2 1:2 
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E^Relation/Cartesian product 1:1process tuples 1:1process Relation 2 2:2 
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g£3Relation/uerify union compatibility 1:1 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 



7ZZZ 

K 



Z ^check tt of attributes^ j(3 

u vy ^ r 







tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZt 



^Relation/uerify union compatibility Irlcheck # of attributes 1:2 



*tr 



VZZZZZZZZZgZZZZSZZZZZZZZZgZZZZZZZ) 
«Relation>> <<Relation» 

^ sr 

%a1lrlt>ut«-nem«^ 2 at t r I b u te - n a me ^ 

i , " I"'" 

^'( length^ ^(length ^ 

n — n 



IeS 



f77777777777?77Aw;;;;;;;;;;;/77777* 



E^Relation/uerify union compatibility 1:1check # of attributes 2:2 



VZZZZZZZZgZZZZZZZZZZZZZZgZZZZZZZ) 
«Relation» «Relation» 




tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZx 



*0 



1. Relations do not have the same number ol attributes, and cannot be unioned together. 
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^Relation/remoue duplicates and write R2 1:2 




GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



^Relation/remoue duplicates and write R2 2:2 



vzzzzzzgzzzzzzzzzgzzzzzzzzzgzzzza 

GZ2ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ2 . I 



^Relation/remoue duplicates and write R2 1:2compare all 1:2 




^Relation/remoue duplicates and write R2 l:2compare all 2:2 



tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZa, 



7ZZZZZZZZQ 
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VTemp Relation 



- 

NULL 

V 

relation name 
NULL 

V 

attribute-names 

NULL 

V 

attr-types 



(jpTemp Relation 



Input: <<Temp Relation», «T©mp Relation», result_name 
Output:«T©mp R©iation» 

union 

Input: «Relation»,list of th© form 
( attribute, operator, value), result_name 
Output: «T©mp Relation» 

selection 

Input: <<T©mp Relation», list of attributes, result_name 
Output: «Temp Relation» 

projection 

Input: «Temp Relation», <<Temp Relation», result_name 
Output: «Temp Relation» 

difference 

Input: «Temp Relation>>, «Temp Relation», result_name 
Output: «Temp Relation» 

Cartesian product 









decompose 



Input: an empty list, the list to be decomposed 
Output: decomposed list 

lists 




Input: an empty list, the list to be decomposed 
Output: decomposed list 



open Temp Reiation 



^Temp Relation/union 1:2 



«Relation 1» «Relation 2» result name 



^//verify' union compatlbilljfl X ^ 3 3 ^ //m a k e Te mp R el a tlo rfo 




^//open Temp Re) at jo % 




^ wrijt^R 1_ to Tem^Rj 



^//decompose list 




Temp ^s^Llst of every 
Relation tuple in R1 




lid a comp o s e ' 'l I s t 



remove duplicates from R2^ |b33 3333333p^:table-clo 8^ 



tZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ2Z 



^Temp Relation/union 2:2 



^ZZZZZZ^Z2Z2ZZZZZ^2ZZZZZZZ^ZZZZ} 

«Relatior«Relation 2» 



§1 



I 



NULL 



GZZZZZZZZZZZZZ 



I 



«Temp Reiation>> 

"zzzzzzzzzzzzzm 



§1. The two relations are not union compatible 
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g^Temp Relation/union 1:2 



«Relation 1» «Relation 2» result name 




^Temp Relation/union 2:2 

vzzzzzgzzzzzzzzzgzzzzzzzzzgz^ 

«Relaliot«Relation 2» 

§1 




NULL 



J «Temp R 



Relation» 

GZZZZZZZZZZZZZZ2Z2ZZZZZZZZZZm 



>1. The two relations are not union compatible 



E^Temp Relation/union 1:2write R1 to Temp R 1:1 



vz zzzzzzzzzzzzzzzzzzzzzzzzzzz^ 




Temp 
Relation 



■ Q 

^table-close^ 

^ u— ^ 



List of every 
instance in R 



f&ZZZSZZZZZZZ2ZZZ!Z!ZZ2ZZZ^ 



^Temp Relation/union l:2make R2 list 1:1 




GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 
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^Temp Relation/union 1:2remoue duplicates from R2 1:2 



vzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz 




GZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ* 



^Temp Relation/union 1:2remoue duplicates from R2 2:2 



^ZZZ22^ZZZZZ2Z^ZZ2Z22ZZ^ZZZZ} 

tzzzzzzzzzzzzzzribzzzzzzzzzzzzzzz& 



^Temp Relation/union 1:2make R2 list 1:1make list 1:2 
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^Temp Relation/union l:2make R2 list t:1make list 2:2 




^Temp Relation/union 1:2remoue duplicates from R2 1:2compare all 1:2 




^Temp Relation/union 1:2remoue duplicates from R2 1:2compare all 2:2 

^ZZZZ2ZZ^ZZZZZZZZZZZ27ZZ^ZZZ2ZZ3 

GZZZZZZZZZZZZZZZZZZZZZZZZZZ2ZZZZZZQ 
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^Temp Relation/selection 1:1 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 
«Relation» 



^ at t rib ule-name^ ....... A..... .. pz,. <Z 7Z~~~~~~T 3 

«ts X' Ed.u.h-a fe?,V J .. T . ?g' . P ... P . « J^ 






-n \ InTi 

[%//open to first ttupjig ( t— ^ “ 3 



_D o o o 



J «Temp Relation» 

£ L 




^aet the tUDlestllb^s^tabie-cl 

Ifnp^nbtsr " r_ 

CZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



E^Temp Relation/selection 1 : 1 get the tuples 1:2 



TZ ZZZZZZZ^^^^^ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ^ 




^ ^key-rea 

yn 


; / & 

fkvi / ^ 


v NLM 


^key-next^'"'" | 


~XZ 


( 


Lor 


^cluster-writ^ 
0 o 



ezzzzzzzzzfczzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz^^ 




^Temp Relation/selection 1 : 1 ge t the tuples 2:2 

VZZZZZZZZZZ^ZZZZ^ZZZZZ^ ZZZZZZZZ} 

tZZZ&ZZZZZZZZZ&ZSZZ ZZZZZZZZZh 
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^Temp Relation/projection 1:1 



_ — -attribute list. result name 

«Relation» — “ 

%//o p e t a b I 333333333 >33j { ^ make temp relation j 






-primary key 
T25 



Temp Relation Inst. 
I E°pen Temp Relation^ 




^key-firs 

— Q 



process all tuples 



Temp Relation instance 

tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzdzzb 



^Temp Relation/projection Irlmake temp relation 1:2 
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^Temp Relation/projection Irlmake temp relation 2:2 



^ZZZ2Z^ZZZZZZZS^ZZZZ22ZZZ^ZZZZ^ 

Relation attribute list 



§1 



fZZZZZZZZZZZZZZZZ^ZZZZZZZZZZZZZZZZA 



0 



(I. One of the attributes selected does not exist in the selected Relation 



^Temp Relation/projection 1:1open Temp Relation 1:1 



v zzzzzzzzzzzzzzzzzzzzzzgzzzzzza 

«Temp Relation» 



7ZZZZZZZ 

/■ , 
^ re I at I on na me^ 




{ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ2ZZZ& 



E^Temp Relation/projection IMprocess all tuples 1:1 



^key-rea'd^ 
_D Q 






^key-nex^ 



Table id 



tZZZZZZZ22&ZZZZZZ22ZZSZZ2ZZZZZZh 
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g^Temp Relation/projection 1:1make temp relation 1:2check attributes 1:2 






TZZZZZZ^ZZZSZZZZ^^Z^ZZZZZ^ 



^attach-r^ 



I 



M3 






OTemp Relation/projection lilmake temp relation 1:2check attributes 2:2 




§2. The attribute: 



£23Temp Relation/projection lilmake temp relation 1:2make types list 1:1 
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t^ Temp Relation/projection 1:1open Temp Relation Irlcreate temp relation table 1:1 




&%3 Temp Relation/projection 1:1process all tuples 1:1write values to Temp Relation 1:1 



() 




"0 0 “ 

tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz 



fe^j Temp Relation/projection 1:1process all tuples Irlwrite values to Temp Relation 1 : 1 get all attributes 1:1 
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^Temp Relation/difference 1:1 




^Temp Relation/difference 1:1R2 to list 1:2 
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E^Temp Relation/difference 1 : 1 R2 to list 2:2 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ7ZZZZZ) 




?do list types 




tZ2ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ& 



OTemp Relation/difference 1 : 1 R 1 to list t:1 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 






\ ^key-read^ 


\ a — ° 9 

0 To/” 5 ” 

\ / 
j^a 1 1 a c h- 


key-next^ 


0 


1J 

1 ! 
L_ 



ES^Temp Relation/difference 1:1uirite R1 - R2 to Temp R 1:2 




155 



E^Temp Relation/difference 1:1 write R1 - R2 to Temp R 2:2 



g Z!ZZZ2ZZZZZZ2ZZZ^ZZ2ZZZ2ZZSZZZ2Z^ 






GZBTemp Relation/difference 1 : 1 R2 to list 1:2do instances 1:1 



V22ZZZ2ZZZ2Z2ZZZZ22ZZZZZ2ZZ^ZZZZZZZZ^ 




jin sito-iisi^ 




(j^ a tt a'c h - r^ 

{zeE^zzzzzzzzzzzzzz&zzzzzzi 



OTemp Relation/difference 1:1R2 to list 2:2do list types 1:1 



V ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 

SL 



j^key-re a 

/ 

0 (1T^333333 o^key-nexi^ 



A 



^attach-ii^ 

75 



GZZZZZZZZZZZ&ZZZZZZZZZZZZZZZZZZ2Z 
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^Temp Relation/difference 1:1 write R1 - R2 to Temp R 1 :211st to simple types 1:2 




^Temp Relation/difference 1:1 write R1 - R2 to Temp R 1:2list to simple types 2:2 



VZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) 

— jL_ 

^attach - r2 

tzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz 



^Temp Relation/difference Irlwrite R1 - R2 to Temp R 1:2compare all 1:2 




fZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZb 



^Temp Relation/difference Irlwrite R1 - R2 to Temp R 1:2compare all 2:2 

VZZZZZZZZZgZZZZZZZZZZZZZZZgZZZZZZZ) 

(ZZZZZZZZZZZZZZZ2ZZZZZZZZZZZZZZZZZZQ 
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g£3Temp Relation/Cartesian product 1:1 



*ZZ2^mZZZZZZZZZZZZZZZZZZZZZZZ^^ 






«Temp Relation» 



«Relation»l 



&!!?. P-? IV, ? l^make Temp relation ^ 



-primary key 



^Tkey-ope 



^ k « y “« I r g ^ 



X 

«Temp Relation»' 



result_name 
«Relation» 



Mo p e n” t a b I e^j 

w .. ...... 

^ : - 33 




process tuplesilllsaKt able-clo 



tzzzzzzzzzzzzzzzzzzzzszzzzzzzzzzzzzzzz^ 



G^Temp Relation/Cartesian product 1:1 make Temp relation 1:1 




§1. relation name 



158 



£231 emp Relation/Cartesian product 1:1process tuples 1:1 




E^Temp Relation/Cartesian product 1:1process tuples 1:1process Relation 2 1:2 
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^Temp Relation/Cartesian product IMprocess tuples 1:1process Relation 2 2:2 
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E^Temp Relation/decompose lists 1:1 



^ZZZZ2^2ZZZZ2ZZZZZZZZZZZZZZZZZZZZ} 



() 



^ list to simple types ^ 



z 



^ a 1 1 a c h 




fZZZZZZZZZZZZZZZZZEZZZZZZ22ZZ2ZZZ& 



OTemp Relation/decompose lists 1 : 1 list to simple types 1:2 




^Temp Relation/decompose lists 1 : 1 list to simple types 2:2 



VZZZZZZZZZZZZZZZZZZZZZZZZgZZZZZZZ} 

su 



£ a 1 1 a c h - 



TZZZZZZZZZZZZZZZu 




r/////////////////?/////,w//;//;;y>/A 
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g^Temp Relation/open Temp Relation 1:1 



V Z2ZZSZSZZZZZZZZZZ^ZZZ2ZZ2ZZZZ} 

T «Temp Relation» 



^ relat {on nia me^ 




^ create' temp f elation table j 1 3 3 3 3 ^/o p'« n t a b I 




-primary key 
T 1 



^key-open^ 

U 7J 



€ZZZZZZZZZZZSZZZ2ZZZZZZZZZZZSZZZ^ 



g^Temp Relation/open Temp Relation 1:1create temp relation table 1:1 



^current DE& 
^ id a t a b a s e I cC-'j 



< TZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZD 



^tabie-new^ 

^ ^ -primary key 

„ zz 

^tabie-clos^ccccccccc^key-new^ 

— o =* o o 

ry;;jAV;///;///////////s/////777777x 
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